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 fedora-devel-list mailing list