Bug Workflow Proposal
[[TableOfContents()]
Overview
Problem Space
There currently is no formal viable, written bug lifecycle within Fedora. This proposal is make a process, applicable to all package maintainers, which addresses the workflow problems that exist currently within Fedora
Proposed Solution
Lifecycle of a bug
1. Reporter files a bug report, it originates in NEW state
1. 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.
1. 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
1. --(Once a developer has taken responsibility for a bug and is actively working on it, the state transitions to ON_DEV.)-- This was a pretty hair brained idea. There are other ways to catch deadbeat maintainers (which this was intended for) JonStanley
1. Once a fix is in CVS, the state of the bug moves to MODIFIED (manually by the maintainer).
1. Once an update addressing a bug exists in Bodhi, and is pushed to updates-testing, the status automatically transitions to ON_QA
1. 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.
After something has been in NEEDINFO(reporter) for 30 days, it is eligible for closure by a member of the triage team after review. The purpose of this review is to simply see if perhaps the information has been provided and the reporter forgot to click the wrong checkboxes, etc.
Closing bugs UPSTREAM
When deciding to tell a user to take a report upstream from Fedora, care should be taken to not alienate the user, who is our most valuable asset. We do not want the user to feel that we told them that they reported the issue to the wrong place, and they should go take care of it somewhere else. However, it is not practical for us to report bugs upstream all the time (after all, it IS the user's bug, they can reproduce, provide additional information, test a fix, etc). We SHOULD search upstream, and determine if a similar report already exists. If it does, then the bug can be closed as UPSTREAM and the user can go join the party upstream. If there is not a matching upstream bug, and the bug is in a component where the Fedora maintainers are not able to fix the bugs and submit the patch upstream, THEN the user should be told to file an upstream bug, and helped in the process, however, the Fedora bug should probably not be closed at that point.
Scope
This proposal would include editing bug triage wiki pages with the new proposal, and all maintainers being bound by the guidelines as a condition of continued maintainer status. cvsextras sponsors would be required to educate new maintainers on this process.
Discussion Points
- ASSIGNED state is counter-intuitive to end-users. However, adding new states is difficult in current RH bugzilla, and would provide little to no increased value in the workflow.
- What is required to gain sponsor status in fedorabugs in FAS?
Comments ?
- --(ON_DEV needs to be given some prominence as is currently not used by maintainers to any great extent)-- Proposal removed JonStanley
- What does RHT use - can someone comment on definitive internal RHT workflow?
(something similar to Fedora, plus some QA stuff, and Errata production; MODIFIED is probably the only one which could be of interest to Fedora, and that's now used by Bodhi as well)
- What happens if bugs are not responded to by maintainer? This may be outside of triage team purview but is major goodwill issue.
PackageMaintainers/Policy/NonResponsiveMaintainers
- IMHO, it would make more sense to use ASSIGNED the way ON_DEV was originally proposed to be used. Rationale: more intuitive to both users and maintainers, matches existing policy better. (I for one have always used ASSIGNED that way.) As for the state where the bug "went past the triage team", I'd argue such a state should not exist, the triage team should "own" the bug as long as it hasn't been taken care of by a developer (by the act of that developer assigning the bug to him/herself). If they feel the bug is ready to be handled by a developer right away, they should try pinging the maintainer and in extreme cases invoke the non-responsive maintainer policy, if there's something still missing, then it shouldn't be handed off to the maintainer yet (but go back to NEEDINFO or whatever). But IMHO changing a bug to ASSIGNED should really be a maintainer decision, not a triage team decision. Active maintainers are probably not going to wait for triage before taking care of bugs, inactive or overworked maintainers are going to let them sit in ASSIGNED just as they used to let them sit in NEW, so the proposed distinction between NEW and ASSIGNED looks pretty arbitrary to me. -- KevinKofler
- Oh, and if ASSIGNED gets used the way suggested in the proposal, any team-maintained packages will have to use ON_DEV for stuff they're actually working on or we'll lose track of what who's doing pretty quickly! -- KevinKofler