Jon Stanley (jonstanley@xxxxxxxxx) said: > 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. > 5) Once an update addressing a bug exists in Bodhi, and is pushed to > updates-testing, the status automatically transitions to ON_QA > 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. So... this conflicts with the RHEL workflow, in that NEW is used for 'no one is looking at this', and ASSIGNED means 'someone is on the hook for that'. I'd prefer something like: UNCONFIRMED -> NEW -> ASSIGNED rather than: NEW -> ASSIGNED -> ON_DEV If no one is currently looking at it, I think 'NEW' conveys that better to the user than 'ASSIGNED'. Bill -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list