This is the mail archive of the
mailing list for the GCC project.
Re: Moving towards GCC 3.1
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: pfeifer at dbai dot tuwien dot ac dot at
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 26 Dec 01 11:36:07 EST
- Subject: 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.