[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora bug workflow - process change



Matej Cepl <mcepl redhat com> wrote:
> On 2008-02-25, 20:05 GMT, Jon Stanley wrote:
> > The ASSIGNED state is a state that has a new meaning - it used 
> > to mean that the bug was actually assigned to a person. 
> > Instead, it now means that the bug is capable of being worked 
> > on by a maintainer - i.e. the triage team believes that this is 
> > a complete, actionable bug - i.e.  with a stack trace for 
> > a crasher, various log files for other components, complete AVC 
> > message for SELinux stuff, etc.
> 
> a) I totally agree not to require retooling — Red Hat Bugzilla 
>    maintainers are totally buzzy with upgrading to Bugzilla 3.2
>    (yay!!!) but Red Hat BZ is so heavily modified that this is
>    crazy amount of work.
> 
> b) ASSIGNED state is really ambiguous, but its definition is not 
>    what is important about it (and believe me, as a former
>    lawyer, I like heated discussions about definitions ;-)). To
>    make further discussion more understandable I will venture
>    with these definitions of ASSIGNED, but I repeat this is not
>    what's important, the further discussion is.
> 
>    So, ASSIGNED could mean:
> 
>    1) The bug has been triaged, and the triager believe that
>       there is nothing she can do about it and further decisions
>       about the bug have to be done by developers. (Further
>       discussion what this actually means would be endless, so 
>       I will skip it here).
>    2) The bug has been put to the sack of particular developer(s)
>       and he will (sometime) work on it.
>    3) The bug is actively being worked on by a particular 
>       developer(s).
> 
> My point is that in this discussion many people seem to confuse 
> 2) and 3). I don't want to indulge here in the discussion whether
> there should be a special state of the bug to distinguish between 
> these two, because I believe that THIS IS TOTALLY OUTSIDE OF THE 
> WORK OF BUG TRIAGERS. Our only job is to get bug to the state 1) 
> (or 2) at the best -- see below), but we have no business to tell 
> developers what they should do.

Distinguishing between 2 and 3 makes no sense. Should the bug move from 3
to 2 when the developer calls it quit for the day, and go back to 3 the
next morning?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]