Fedora bug triage - workflow proposal
Rahul Sundaram
sundaram at fedoraproject.org
Tue Jan 15 13:37:27 UTC 2008
Jon Stanley wrote:
>
> 1) Reporter files a bug report, it originates in NEW state
Can we renamed this state to UNCONFIRMED?
> 2) Triage team looks at bug report, determines if dupe or
> insufficient information exists to solve it. If there is not enough
> information in the bug, then triage team puts the bug in NEEDINFO. As
> you will see below, this state has a finite life cycle associated with
> it.
> 3) Assuming bug survives through the triage team, it changes state to
> ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as
> appropriate). Note that per the definition[1], ASSIGNED does not mean
> that someone has actually agreed to take action, simply that the issue
> is well defined and triaged accordingly
Wouldn't a state like TRIAGED be more meaningful then? ASSIGNED
frequently is assumed to be assuming ownership by the maintainers.
> 4) Once a developer has taken responsibility for a bug and is
> actively working on it, the state transitions to ON_DEV.
If ASSIGNED is renamed to TRIAGED, then this state can be known as
ASSIGNED instead.
> Setting severity is fine. Only QA or releng should set priorities.
> This allows us to look at things in a sane manner (which is impossible
> now since severity and priority fields come from /dev/urandom
> seemingly), and possibly lessen the reliance on blocker bugs (though
> blockers are useful in their own right, so don't think that we are
> going to eliminate them any time soon).
I believe bugzilla folks are recommending the usage of flags over
blocker bugs.
> It was also decided that when a bug is in NEEDINFO for one month, it
> will be closed. Maintainers would need to realize that putting a bug
> in NEEDINFO is putting it on the fast track for closure.
Would a stock message be send to the bug reporters when closing bugs?
Would a separate Fedora page in bugzilla.redhat.com be useful?
Rahul
More information about the devel
mailing list