On Wed, Jun 15, 2011 at 3:23 AM, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi,
This is an update to the bug management process. The wiki page is: https://wiki.linaro.org/Cycles/BugManagement
Cheers,
Fathi
Bug escalation procedure
It's important that bugs which affect the LEB's and other images are caught early and fixed as soon as possible. To help the Linaro Release Team in identifying and tracking the release blocker bugs, any individual could propose a bug as a blocker and follow the bug escalation procedure.
Prerequisite
- All bugs in a 'New' state should be sufficiently triaged to determine their
importance.
- All bugs in a 'High' or 'Critical' state should be highlighted to the Linaro
Release Team: Please, add it to the wiki page 'Bugs' section for the next release meeting. The release meeting calendar can be found on the wiki. Meetings are held on Thursday. If possible, attend the meeting.
Procedure
- Subscribe Linaro Release Team ('linaro-release') to the proposed bug.
- Linaro Release Team evaluates the proposed bug.
2a. Linaro Release Team accepts the bug as a release blocker: * notify by a comment on the bug. * set the milestone to the next release. * assign to the appropriate team. 2b. Linaro Release Team rejects the bug as a release blocker: * unsubscribe Linaro Release Team from the poposed bug.
How does this relate to working group outputs?
Here's my process BTW: https://wiki.linaro.org/WorkingGroups/ToolChain/BugProcess
It's unusual for a bug to be a release blocker as there's normally some type of work around. I'd normally only stop or respin a release if the bug is embarrassing (which I guess is equivalent to Critical :)
-- Michael