This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Suggestion for a new GNATS policy
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: "S. Bosscher" <S dot Bosscher at student dot tudelft dot nl>
- Cc: 'Volker Reichelt ' <reichelt at igpm dot rwth-aachen dot de>,"'gcc at gcc dot gnu dot org '" <gcc at gcc dot gnu dot org>,"'bangerth at ices dot utexas dot edu '" <bangerth at ices dot utexas dot edu>,"'giovannibajo at libero dot it '" <giovannibajo at libero dot it>
- Date: Sun, 11 May 2003 20:58:18 -0400
- Subject: Re: Suggestion for a new GNATS policy
So IMHO we need some stricter requirements for reports in state
"analyzed". Knowing that any analyzed PR is in the right class and
has a simple testcase attached and a suitable synopsis line would
help the bug fixers to do their work efficiently.
We should have a "confirmed" state, which would mean that somebody
with GCC
PR DB write access can reproduce the bug (possibly after receiving
feedback).
This is "NEW". There is an UNCONFIRMED state for UNCONFIRMED bugs.
"analyzed" should mean that at least the category is set and
that a reduced test case is available.
Why?
you can mark them with a keyword or bug status flags.
Stop overloading bug states for this functionality.
Geez.
Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED"
if assigned to someone, "NEW" otherwise).
Aieee, please no. There are so many analyzed PRs that are
unassigned, so what you say here would only make things harder.
We should have "NEW" for new and unconfirmed PRs and "CONFIRMED"
for confirmed PRs. PRs should have the "ANALYZED" status when
somebody has zoomed in at the problem a bit closed. PRs that are
"analyzed" now should stay "ANALYZED" in bugzilla IMHO.
These should be bug flags, *not* states.
I don't know how many states you defined, gcc.gnu.org/bugzilla
used to work but now it fails...
Chris upgraded perl today, apparently.
Needs to reinstall some packages.
(Does Bugzilla allow you to
define your own states at all???)
Yes, but there is no need in this case.
In most cases, there is no need. One just has to remember to
put the right thing in the CVS commit message, and it'll get
added to the PR as a comment.
It's not unusual for a PR to be fixed without anyone noticing.
For 3.3, I closed some PRs that got fixed by some patch, but
the CVS commit message didn't mention the PR (probably because
nobody knew about the PR...) so the PR stayed open. I think
everybody has seen PRs like that.
You can easily query for bugs that haven't (or have) been
touched in x days in Bugzilla, so there is no need to put
timestamps on bugs and whatnot.
You can do that with GNATS, too. Just not very user friendly,
it _can_ be done.
Greetz
Steven