Hi,
This is an update to the bug management process. The wiki page is: https://wiki.linaro.org/Cycles/BugManagement
Cheers,
Fathi
On Tue, 14 Jun 2011 15:23:13 +0000, Fathi Boudra fathi.boudra@linaro.org wrote:
- 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.
Why do we notify the release team both through editing a wiki page and subscribing the team?
Thanks,
James
On 14 June 2011 15:36, James Westby james.westby@canonical.com wrote:
On Tue, 14 Jun 2011 15:23:13 +0000, Fathi Boudra fathi.boudra@linaro.org wrote:
- 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.
Why do we notify the release team both through editing a wiki page and subscribing the team?
It's part of the previous process. It makes sure we have high/critical bugs under the radar. These bugs aren't qualified as release blocker yet (or even proposed).
Do you think it's a duplicate effort and whatever a bug importance is, it could be proposed? In any case, the triage will be done at the Release Team level.
Cheers,
Fathi
On Tue, 14 Jun 2011 16:02:00 +0000, Fathi Boudra fathi.boudra@linaro.org wrote:
On 14 June 2011 15:36, James Westby james.westby@canonical.com wrote:
On Tue, 14 Jun 2011 15:23:13 +0000, Fathi Boudra fathi.boudra@linaro.org wrote:
- 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.
Why do we notify the release team both through editing a wiki page and subscribing the team?
It's part of the previous process. It makes sure we have high/critical bugs under the radar. These bugs aren't qualified as release blocker yet (or even proposed).
Do you think it's a duplicate effort and whatever a bug importance is, it could be proposed? In any case, the triage will be done at the Release Team level.
I think it's duplicate.
I think there should be one method to put bugs on the release team radar, and it should be simple. If we are doing it purely based on importance of the bug then let's do it by reporting those bugs automatically, rather than having people manually move things over to a wiki page.
I would personally like to have just the subscription method, and the release team to work from their subscribed bugs, raising things in the meeting if they need to be raised.
Thanks,
James
On 14 June 2011 17:47, James Westby james.westby@canonical.com wrote:
I would personally like to have just the subscription method, and the release team to work from their subscribed bugs, raising things in the meeting if they need to be raised.
Updated in that sense.
Cheers,
Fathi
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
On 14 June 2011 21:53, Michael Hope michael.hope@linaro.org wrote:
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 :)
A bug can be qualified as a release blocker after the WG release, probably during Platform integration coming after your component release. It will result that the bug will be under the release team radar and we'll work together to fix it in time for the Platform release, most likely a respin is needed.
I think the escalation procedure ensure that we're on the same page and fit next to your bug process.
Cheers,
Fathi
On Thu, Jun 16, 2011 at 11:06 PM, Fathi Boudra fathi.boudra@linaro.org wrote:
On 14 June 2011 21:53, Michael Hope michael.hope@linaro.org wrote:
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 :)
A bug can be qualified as a release blocker after the WG release, probably during Platform integration coming after your component release. It will result that the bug will be under the release team radar and we'll work together to fix it in time for the Platform release, most likely a respin is needed.
I'd prefer to add a work-around to the package than respin. If no work around exists and the package is important enough then we can fix and respin, but note that any change to the compiler may affect a different package.
-- Michael
On 16 June 2011 23:38, Michael Hope michael.hope@linaro.org wrote:
On Thu, Jun 16, 2011 at 11:06 PM, Fathi Boudra fathi.boudra@linaro.org wrote:
On 14 June 2011 21:53, Michael Hope michael.hope@linaro.org wrote:
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 :)
A bug can be qualified as a release blocker after the WG release, probably during Platform integration coming after your component release. It will result that the bug will be under the release team radar and we'll work together to fix it in time for the Platform release, most likely a respin is needed.
I'd prefer to add a work-around to the package than respin. If no work around exists and the package is important enough then we can fix and respin, but note that any change to the compiler may affect a different package.
I guess it will be discussed on a case by case basis between you and Ricardo. Otherwise, sounds good to me.
Cheers,
Fathi
-
Fathi Boudra -
James Westby -
Michael Hope