httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: bug database: difference between "analyzed" and "feedback"
Date Thu, 21 May 1998 06:46:32 GMT
On Wed, 20 May 1998, Brian Behlendorf wrote:

> At 10:39 PM 5/20/98 -0400, you wrote:
> >Brian Behlendorf wrote:
> >> 
> >> 
> >> Just to check people's gut reaction, the semantic distinction I'm making is
> >> that "analysed" means we have started the correspondance, perhaps have
> >> proposed some quick fixes, and then finally have a firm idea of the causes.
> >>  "Feedback" means we have a proposed fix sent to the bug reporter, and if
> >> it fixes their problem we move to closed.  Does that make sense?
> >> 
> >
> >I've always considered Feedback as "we need some more info about
> >the bug before we can proceed any further" and Analysed meaning
> >"we understand the problem and know where in the code the problem
> >is"
> 
> I was basing my notion on the fact that the gnats bug database interface
> defines 5 stages, in this order:
> 
> open  -->  analysed --> suspended --> feedback --> closed
> 
> which matches the process of
> 
> bug submitted
> it gets reviewed
> patch worked up
> patch sent back to bug reporter, see if it fixes their problem
> problem solved.

The problem is that most bug reports either fall into the category of
submitter is crazy/submitter has broken OS _or_ they can be easily
reproduced so it really isn't necessary to have the submitter test the
patch.  Yes, there are some where we get the submitter to try a patch
without knowing if it will solve the problem, but that is the exception.

I don't think suspended fits in the above sequence where you have it.

My views:

open: the report has been submitted.  No cause or probable cause or real
idea about where to go next has been formed.  Could be some initial extra
questions.

analyzed: it moves into this state when some substantive "analysis" of the
PR happens.  This means that there should be either a patch, a concept
recorded of how it has to be fixed, or a solid direction that the PR is
going in is established.  If the fix is given in the PR, it doesn't moved
to analyzed but remains in open unless additonal "analysis"  is done.

suspended: for changes that aren't trivial (either technically,
politically, etc.) or can't be done at the moment.  It _isn't_ a "thrown
on the dung pile" state, but a keeping grounds for things to be done,
often involving a fair chunk of work.  A lot of feature requests sent to
the bugdb end up here.  Isn't ideal, but is the best state given the use
of one database for features and bugs.

feedback: for whatever reason, it is blocked on a read from the user.
This could be waiting for verification of a patch.  It could also go into
this straight from open when a silly submitter gives insuficient
information.

closed: poof.  Done, gone.  Note that closed isn't necessarily closed
since we have more than one code tree, but that's life.

>From what I recall of reading the gnats "process model" (wasn't drunk but
may as well have been for all I remember), it doesn't apply at all to the
way we do business so we need our own definitions.

> 
> 	Brian
> 
> 
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> pure chewing satisfaction                                  brian@apache.org
>                                                         brian@hyperreal.org
> 


Mime
View raw message