This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Assigning priorities to GNATS reports
- From: Joe Buck <jbuck at synopsys dot com>
- To: bangerth at ticam dot utexas dot edu (Wolfgang Bangerth)
- Cc: gcc at gcc dot gnu dot org, reichelt at igpm dot rwth-aachen dot de
- Date: Thu, 14 Nov 2002 08:20:01 -0800 (PST)
- Subject: Re: Assigning priorities to GNATS reports
Wolfgang Bangerth writes:
> Now that the bug fixing phase for 3.2.1 is (mostly) done,
Consider it done; I'd think Mark probably has the cycles to put in about
one more bug fix at most, if he allows any at all. The rest will have to
be done in 3.2.2 or 3.3.
> what is the
> policy on setting priorities to bug reports if they are regressions? I
> think the last couple of weeks have shown that we can come up with large
> numbers of regressions and mark them as "high" until the last minute
> before the release. This way, there will always be known regressions if we
> just go on sifting through the database.
As you sift, please mark any regressions you find as "high", and
especially for old bugs, as confirmed still present in whatever
version you test with.
> I think the only way to avoid this is to _always_ mark regressions as
> "high", even if we are not close to a release. This way, regressions would
> be known for longer and not only days before an anticipated release,
> giving more time to fix them. Should this be policy for us bug database
> crawlers?
Yes, it's best to expose all regressions that show up in our bug database
as soon as we can. It makes no sense to wait until a release is about to
happen to notice that a bug reported six months ago is a regression.
> PS: Looking at the number of bugs fixed for 3.2.1, I really lift my hat
> towards those who did it! Thanks!
Strongly agreed.