Suggestion for a new GNATS policy

[Daniel Berlin]

Here guys, as an example, i added a verified flag and a minimized flag 
for bugs.

Since Chris upgraded perl, and bugzilla on sources is currently thus 
out of order, try http://www.dberlin.org/bugzilla/

choose a random bug to see the flags.
There is an interface for adding keywords and flags to bugs/attachments.

I'll make it so the flags are queryable  easily



On Sunday, May 11, 2003, at 05:52  PM, 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.
>
> 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
>