This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GNATS web interface unusable


>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

Joseph> http://gcc.gnu.org/ml/gcc/2002-02/msg00692.html

I've never understood the use or meaning of `suspended'.  I'm
reluctant to ever put a bug into that state, since it means the bug
just disappears.  I think I'd rather either close a bug ("we won't
ever do this") or just make sure it isn't assigned to any upcoming
milestone ("we'll fix it someday, but it isn't release critical") and
leave it open (actually analyzed, with a note explaining the
situation).

Is there really value in having assigned and reopened be separate?
Can you close and reopen a report without ever assigning it?  Whenever
I close a report I assign it to myself; maybe that should be policy.

I like having analyzed.  I don't understand why reopened needs its own
state.  So I'd say remove reopened, change unconfirmed->new, and
new->analyzed.

Does assigned need to be a state?  A bug could be feedback and
assigned.  I think these are orthogonal.

So I suggest statuses much like Gnats: NEW, ANALYZED, FEEDBACK and
CLOSED; resolutions: FIXED, INVALID, DUPLICATE, WORKSFORME.
Assigned and milestones would be separate axes.


Apparently (and it surprised me), I'm basically looking for Gnats
Plus: Gnats, with some weirdness removed, and with some nice useful
features like duplicates, dependencies, and milestones.

That said, I'm sure I will adapt to whatever system is put in place.
I definitely would like to understand the reasons for all the states
Joseph proposed in his message.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]