Suggestion for a new GNATS policy

[Daniel Berlin]

On Sunday, May 11, 2003, at 10:00  PM, Giovanni Bajo wrote:

> Daniel Berlin <dberlin@dberlin.org> wrote:
>
>>>   "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.
>
> No, in my opiniton it's totally the contrary. "Confirmed" should be 
> just a
> flag. I don't care if a bug is confirmed or not:

Because you only look at *bugs*, not other things tracked through the 
bug system, like enhancements.
>  confirming is a no-brain
> action: it means I downloaded the PR, run GCC on it, and verified the 
> bug.
> To push it, it could even be automated for 
> c++/c/middle-end/optimization
> bugs (especially ICEs). I don't think anybody really cares if it's been
> confirmed that a 300K file ICEs the compiler: the real problem is an
> effective analysys of the bug, which means testcase reduction, code 
> forming
> check, and such.
There are also bugs that are *not* bugs.
They can be about enhancements, patches, whatever.
Not everything is a bug.
> This is what it's really important. I don't really mind about the 
> name, but
> if Bugzilla doesn't have "analyzed" but only "uncorfimed" and "new", we
> should use "new" as analyzed.
The reason there is no "analyzed" is because not everything is a bug 
that needs any of these things done to them.
It's the wrong term.
>
> Otherwise, please explain us what is a state and what is a flag. 
> Usually, a
> bug which is not properly analyzed will not be considered for 
> bugfixing,

There are plenty of people who look at bugs without minimal testcases, 
or look at enhancements.
>  so
> this is where the stress should go.
> I call this a bug state.
>  Confirmation is
> not necessary a state (it's mostly useless),

Enhancements can be tracked *without* a testcase at all, but they need 
to be confirmed that they don't exist currently in bugzilla.

There are also people who use Bugzilla to track branch landings and 
whatnot ("meta bugs"), so that you can set a bug expected to be fixed 
by the branch merge as being dependent on the branch landing "bug".

There is more than just bugs in a bug database.
>  so I'm ok with it being just a
> flag.
>

Renaming or removing the built-in states is not something i will do.  
It requires trivial modifications to a lot of files, that cause merge 
problems later on.
I can add states with coding changes grudgingly, for the same reason. 
It's easier to add than rename or remove, but still causes some 
problems.
You can add/remove/edit available flags for bugs with a simple web 
based interface as much or as little as you want.

I don't understand why you seem to want tons of bug states. Nobody can 
juggle them in their head anyway.

To answer your question about the distinction between flags and states, 
there is no general distinction, so i'll make an arbitrary one for you:

In general, states are things  that most developers care about in the 
life cycle of a bug.
We are simple folk in this regard.
If it's a bug, we fix it.
An enhancement, we add the enhancement (or mark it as wontfix).
etc
When fixed, we mark it fixed.
We don't need to know whether a bug has a minimized testcase, or if 
it's been reconfirmed recently.
If these are requirements to something being a "NEW" (for lack of a 
better term) bug, that's fine.
It just means as far as we are concerned, it's not a bug we want to fix 
yet, because it's not "NEW".

Bug flags are things you guys can use to track your workings on a bug 
(like whether it's been reconfirmed recently, whether it's got a 
minimized testcase, etc), including things you use to determine when 
*you* move a bug from one state to another.  These are generally a set 
of requirements that can be expressed as booleans. "Does it have a 
minimized testcase?", or a combination of a boolean and a date/time 
when the boolean was last changed ("Has it been reconfirmed? When was 
it last reconfirmed?").
Developers aren't going to really care about the bug flags (If we use 
bugzilla for patch tracking or branch tracking or whatnot, we'd care 
about attachment flags, which are different).

I can go further with this arbitrary distinction if you like, but it 
suffices to keep developers from juggling 40 different bug states, and 
gives you guys a place to track things, without having to put them in 
the subject.

I'll note also Bugzilla allows attachments to have flags as well (it's 
a separate namespace of flags than bug flags).
Attachment flags can be set because of a new attachment (IE you can say 
obsolete was added to attachment x because of new attachment y).
You could simply mark the old attachment as obsolete (which is a 
built-in attachment flag), and flag the new attachment as "minimized", 
rather than flagging the *bug* as minimized, since it's the attached 
testcase that is minimized, not the bug.
YOu could also mark the original testcase attachment as minimized if it 
is minimized.
This is actually where minimized belongs, since it's a property of a 
testcase for a bug (which is supposed to be in an attachment, no?), not 
a bug itself.



> Giovanni Bajo
>