> 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: > > 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. A question - what about bugs blocked by another bug. For example, I have a tracker bug to build plplot for ppc64 once Ada is built for ppc64, and is blocked by the Ada for ppc64 bug. Is there some easy way for it to show up in my bug list as obviously "blocked"? - Orion -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
