You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@hyperreal.org> on 1998/05/21 03:54:39 UTC
bug database: difference between "analyzed" and "feedback"
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?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction brian@apache.org
brian@hyperreal.org
Re: bug database: difference between "analyzed" and "feedback"
Posted by Dean Gaudet <dg...@arctic.org>.
+1
On Thu, 21 May 1998, Brian Behlendorf wrote:
>
> OK, so it sounds like the critical difference (in people's opinions) is
> that reports which are valid complaints against our current code should
> remain in "analyzed" until a fix is developed, whereas a new feature
> request should be put in "suspended". Which means those who have a
> hunkering to fix real, identified, vetted problems should only have to open
> the bug database and look at all the "analyzed" problems and start fixing
> from there. It also seems like bugs should go from open to feedback if
> more info is needed before going into "analyzed".
>
> Brian
>
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> pure chewing satisfaction brian@apache.org
> brian@hyperreal.org
>
Re: bug database: difference between "analyzed" and "feedback"
Posted by Brian Behlendorf <br...@hyperreal.org>.
OK, so it sounds like the critical difference (in people's opinions) is
that reports which are valid complaints against our current code should
remain in "analyzed" until a fix is developed, whereas a new feature
request should be put in "suspended". Which means those who have a
hunkering to fix real, identified, vetted problems should only have to open
the bug database and look at all the "analyzed" problems and start fixing
from there. It also seems like bugs should go from open to feedback if
more info is needed before going into "analyzed".
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction brian@apache.org
brian@hyperreal.org
mod_javascript mailing list
Posted by Magnus S <so...@Minsk.DoCS.UU.SE>.
The mailing list for mod_javascript can be found at:
http://www.docs.uu.se/~soderman/maillist.html
mod_javascript version 0.11 can be downloaded at:
http://www.geocities.com/TimesSquare/Fortress/9743/binjs.html
/Magnus
Re: bug database: difference between "analyzed" and "feedback"
Posted by Ben Laurie <be...@algroup.co.uk>.
Rodent of Unusual Size wrote:
>
> Brian Behlendorf wrote:
> >
> > 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
>
> I rather agree with Jim and Marc. The way I've been using it maps to
>
> Suspended: Marked for future consideration, nothing going to be done
> right now.
> Analysed: We know (or think we do) what the problem is, and can either
> reproduce it or know how to at need. We don't necessarily
> know what the fix is, or if we do we haven't implemented it
> yet. In short, the problem is understood but just not fixed yet.
> Feedback: The submitter has been asked a question, and we haven't
> gotten an answer yet.
> Closed: Non-problem or fixed.
> Open: Everything else, including no-one having touched it, answer
> to query received but not yet acted upon, and 'no clew.'
+1
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: bug database: difference between "analyzed" and "feedback"
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Brian Behlendorf wrote:
>
> 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
I rather agree with Jim and Marc. The way I've been using it maps to
Suspended: Marked for future consideration, nothing going to be done
right now.
Analysed: We know (or think we do) what the problem is, and can either
reproduce it or know how to at need. We don't necessarily
know what the fix is, or if we do we haven't implemented it
yet. In short, the problem is understood but just not fixed yet.
Feedback: The submitter has been asked a question, and we haven't
gotten an answer yet.
Closed: Non-problem or fixed.
Open: Everything else, including no-one having touched it, answer
to query received but not yet acted upon, and 'no clew.'
I rather wish there were an 'in analysis' stage to fit between
Feedback and Analysed. Not the first time I've missed it, either.
My take..
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: bug database: difference between "analyzed" and "feedback"
Posted by Marc Slemko <ma...@znep.com>.
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
>
Re: bug database: difference between "analyzed" and "feedback"
Posted by Brian Behlendorf <br...@hyperreal.org>.
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.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction brian@apache.org
brian@hyperreal.org