Dan wrote:
On Sunday, May 11, 2003, at 04:30 PM, Volker Reichelt wrote:
1) The state "analyzed" does not help much, because the requirements
are too weak: It just means that somebody has looked at it and agrees
that there's a bug in GCC. Very often not even the class of the PR is
set correctly. Preprocessed files (especially for C++ bugs) are often
huge so that somebody who tries to fix a bug has to do major work
(which could be done by somebody else) before being able to tackle
the core of the problem.
I agree. For many PRs, "analyzed" now just means "yup, I see it, too",
which is not what I call analysis :-)
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). "analyzed" should mean that at least the category is set
and
that a reduced test case is available.
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.
I don't know how many states you defined, gcc.gnu.org/bugzilla
used to work but now it fails... (Does Bugzilla allow you to
define your own states at all???) But I suppose we should have
"NEW", "FEEDBACK", "CONFIRMED", "ANALYZED", "ASSIGNED", "CLOSED",
"REOPENED" (yes this happens), and "SUSPENDED".
(Yes that's very much like what we have in GNATS now, but that's
because
GNATS is not so bad, really. It just misses one or two states and its
user
interface is very poor.)
2) To close the PRs that got fixed silently the PRs have to
be revisited from time to time. But there should be some way
to give the PR's a time stamp so that one can easily see
(without having to read the whole audit-trail) when a PR
should be revisited again.
There's also the "Last-Modified" field, what is wrong with that?
Now all the synopses are being cluttered with date stamps, and
that is IMHO just wrong. The markers like [New parser],
[<some_target>], etc. are useful, because they make it so much
easier to find related PRs real quick. The date stamps don't
do anything that can't be done with basic GNATS functionality,
at least AFAICT.
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