Re: A new axis for bugs?

[David Coe]

Michael Stone <[EMAIL PROTECTED]> writes:

[...]
> On Wed, Oct 06, 1999 at 02:34:20AM -0400, Branden Robinson wrote:

[...]
> > unreproduced
> > reproduced
> > possible fix
> > known fix
> > 
> > Basically I see bug fixing as proceeding sequentially down this list.
> > There's a state above "unreproduced", which is "not a bug", and you close
> > it almost immediately.  There's also the state after "known fix", which is
> > implementation, and is reflected by closing it or setting its severity to
> > "fixed".

There's another state before "unreproduced" -- maybe "unacknowledged"; i.e. 
the maintainer has not responded to the submitter (via the BTS).  We could
then more easily find old bugs that have apparently been ignored.

Re: A new axis for bugs?

[Michael Stone]

[moved to -devel]

On Wed, Oct 06, 1999 at 02:34:20AM -0400, Branden Robinson wrote:
> I like this idea, but I think it is orthogonal to the existing bug
> categories.
> 
> I don't know what you would call it, but I imagine a 4-way status switch:
> 
> unreproduced
> reproduced
> possible fix
> known fix
> 
> Basically I see bug fixing as proceeding sequentially down this list.
> There's a state above "unreproduced", which is "not a bug", and you close
> it almost immediately.  There's also the state after "known fix", which is
> implementation, and is reflected by closing it or setting its severity to
> "fixed".

This is great. The BTS is our institutional memory, and we really need a
mechanism for organizing it. This might do it. It would also make things
easier for people who are trying to help fix bugs--they could filter out
already-fixed bugs more easily and focus their attention on the stuff
that really needs work.

Mike Stone


pgp18TFzhGlgN.pgp
Description: PGP signature