Re: Suggestion for a new GNATS policy

[Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>]

On 11 May, S. Bosscher wrote:
> 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.

Me too: Aieee, please no!
We would lose a *lot* of valuable information and would force much more
work on the bug fixers, leaving the "bug report preprocessors" unemployed.

> 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".

I don't know if we really need REOPENED. A PR should go into "CONFIRMED"
or "ANALYZED" then, IMHO.

If we cannot get these states into bugzilla, we could make dummy
maintainers called "CONFIRMED" and "ANALYZED" etc. to whom we assign
the PRs, but that's only an ugly kludge.

> (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?

Because a new addition to the audit-trail doesn't mean that the
PR was really rechecked. Modified doesn't imply reconfirmed.

> 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.

I'd prefer shorter synopsis lines, too. So, if we can have a seperate
field for the date stamp in bugzilla, I'm in for it. But as long as we
don't have one the information should be stored in the synopsis line IMHO.

>> 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.

Right. That's the reason for the time stamps.

>> 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.

Once again: "touched" doesn't mean "reconfirmed".

> 
> Greetz
> Steven

Regards,
Volker