On Wed, Jun 15, 2011 at 3:23 AM, Fathi Boudra <fathi.bou...@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 > --------- > > 1. Subscribe Linaro Release Team ('linaro-release') to the proposed bug. > 2. 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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
