Fedora bug triage - workflow proposal

John Poelstra poelstra at redhat.com
Tue Jan 15 18:54:06 UTC 2008


Jon Stanley said the following on 01/14/2008 11:46 PM Pacific Time:
> Well, it was a great session at FUDCon.  A lot came out of it, and I'm
> going to put some of them down here. The work flow suggested below I'd
> a FESco vote on, since it really affects you guys.  This work flow was
> discussed between myself, John Poelstra, and Will Woods at the Sunday
> hackfest, and we agree that this is the correct way to move forward,
> however, we want community input and buy-in on this, since it has
> pretty far-reaching consequences.
> 
> Here is the lifecycle of a bug:

During our discussion we looked at this page:
https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_status

After a careful review we found that we agreed with each of the 
descriptions of the states as stated and thought it reasonable to 
proceed with them.

Our goal is to get this launched ASAP and to reuse as much existing 
stuff we can--where it makes sense.  With that in mind, there is a 
little bit of Red Hat centric stuff on this page, nothing to get excited 
about.  I think our goal should be to keep the process as simple as 
possible by using the fewest number of states possible.

> 1)  Reporter files a bug report, it originates in NEW state
> 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
> 4)  Once a developer has taken responsibility for a bug and is
> actively working on it, the state transitions to ON_DEV.

I think ASSIGNED is fine.  Do we gain that much from adding ON_DEV to 
the process?

> 5)  Once an update addressing a bug exists in Bodhi, and is pushed to
> updates-testing, the status automatically transitions to ON_QA

A *future* feature here might also be the ability to automatically 
change a bug to VERIFIED if enough positive feedback is received by 
bodhi.  This would require the ability to give individual bug feedback 
to bodhi vs. a package.

> 6)  When the update is pushed to stable, Bodhi optionally closes the
> bug automatically.  If the update does not auto-close the bug, it
> transitions to NEEDINFO_REPORTER, with a comment explaining that the
> update has been pushed to stable, and to update and test in the new
> release.
> 
> Note that at any step of the above process, the maintainer can "fast
> track" the bug, and change it to ASSIGNED.  The triage team is not
> going to look at bugs that are not in NEW or NEEDINFO state.  On the
> flip side of that, it is not a maintainer's responsibility to look at
> bugs that are in NEW any longer.  They can focus their energy on the
> bugs that are ASSIGNED to them.
> 
> Also, maintainers should not be allowed to set priority on bugs.
> 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).

We talked about this, but I thought we agreed that it made the most 
sense to keep using blocker bugs and that ironing out how to use 
priority and severity was something to worry about after establishing 
some success with a new triage process.

John




More information about the fedora-devel-list mailing list