RE: Suggestion for a new GNATS policy

["S. Bosscher" <S dot Bosscher at student dot tudelft dot nl>]

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