This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Moving towards GCC 3.1

      During this period, the ONLY CHANGES that may be made to the compiler
      are changes THAT FIX BUGS. (Emphasis is mine.)

    Still, I regularily see patches which do not resolve bugs in our GNATS
    database, nor do they have a new testcases:

There are numerous types of patches that fix bugs that fall into neither
of the above two categories:

(1) Fixing existing testcase failures on a particular target.
(2) Fixing build failures on a particular target.
(3) Fixing latent bugs
(4) Fixing documentation or code quality issues
(5) Fixing bugs in proprietary test cases

      [ChangeLogs removed from my first draft of this message]

    I think our goal is/should be to have something that is very close to
    a release when we actually perform the release branch, so most (if not
    all) patches now should either fix a GNATS PR or come with a testcase
    demonstrating a problem.

I think the important thing is that every message submittting a patch (but
not necessarily the ChangeLog) identify the bug being fixed, but the two
methods you list (new testcase or PR reference) are not the only way
to do that.  We do not want to discourage bugs in the above five categories
from being fixed.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]