Here's a short summary of the discussion in the Gecko meeting today:
A) Definitions (or "Threat Level" as Vlad put it):
Tree Control Level 0/Green: Open tree. Checkin after r+/sr+ only Tree Control Level 1/Yellow: 1.9+, wanted-1.9 bugs auto-approved. Other changes require explicit approval flags Tree Control Level 2/Orange: 1.9+ bugs auto-approved. Other changes require explicit approval flags Tree Control Level 3/Red: all check-ins require explicit approval flags prior to check-in
B) Approval Plan:
After M7: we'll re-enter Yellow as planned. Two weeks before M8: we'll enter Red After M8: we'll re-enter Yellow Two weeks before M9: we'll enter red and stay there for the rest of the release
I'm not sure if there was wide consensus on this - which was an attempt to balance risk mitigation against administrative overhead.
C) Branch Plan:
There was general desire here to: a) Branch as late as possible (prevent having to double-checkin + replicate infrastructure) b) Make sure we didn't lockout folks doing non 1.9 work c) Move to Hg as soon as possible
Challenges: a) Hg infrastructure not fully up (no bonsai, lxr, etc) b) Build, unit test, performance test infrastructure not setup for either Hg or a new branch (this is a bunch of work)
Plan: We didn't get to a concrete plan here - besides the feeling that as long as the trunk wasn't under super-strict (e.g. Red with aggressive rejection of patches) control we didn't have to branch right away. Given the above approval plan it seems like we'd need to either get everyone over to Hg or branch around M9. We need to get a concrete transition plan together for Hg and the infra and then we can set a firm date.
Thoughts? Most important part to nail down ASAP is the Approval Plan (B) above. So please either propose something different or lets move forward.
> Here's a short summary of the discussion in the Gecko meeting today:
> A) Definitions (or "Threat Level" as Vlad put it):
> Tree Control Level 0/Green: Open tree. Checkin after r+/sr+ only > Tree Control Level 1/Yellow: 1.9+, wanted-1.9 bugs auto-approved. Other > changes require explicit approval flags > Tree Control Level 2/Orange: 1.9+ bugs auto-approved. Other changes > require explicit approval flags > Tree Control Level 3/Red: all check-ins require explicit approval flags > prior to check-in
> B) Approval Plan:
> After M7: we'll re-enter Yellow as planned. > Two weeks before M8: we'll enter Red > After M8: we'll re-enter Yellow > Two weeks before M9: we'll enter red and stay there for the rest of the > release
I'm wondering if a use case of Orange is missing, or whether its use cases just died in the discussion. I didn't get all the back'n'forth on the phone.
> After M7: we'll re-enter Yellow as planned. > Two weeks before M8: we'll enter Red
Why red, instead of orange? Locking down checkins for blocker bugs this early in the game (pre-beta) seems excessive. Going to a "red" scheme a few days before release seems reasonable to avoid introducing instability/delays right before the beta.
Also, are we explicitly stating that checkins that are not part of the Firefox default build are exempt from these requirements (this includes port-specific work for OS/2, photon, etc)?
> C) Branch Plan:
We're talking about branching 1.9.1 from 1.9, correct? Do we even have a good understanding of what kinds of things we're taking for 1.9.1?
> Challenges: > a) Hg infrastructure not fully up (no bonsai, lxr, etc)
The HTTP viewer at http://hg.mozilla.org/ has *most* of the features of bonsai, though it misses a couple important ones such as line-number-anchors.
Benjamin Smedberg wrote: > The HTTP viewer at http://hg.mozilla.org/ has *most* of the features of > bonsai, though it misses a couple important ones such as line-number-anchors.
It can do "show me the checkins between these two dates" searches? That's the #1 most important feature of Bonsai for regression-finding.
> Here's a short summary of the discussion in the Gecko meeting today:
> A) Definitions (or "Threat Level" as Vlad put it):
> Tree Control Level 0/Green: Open tree. Checkin after r+/sr+ only > Tree Control Level 1/Yellow: 1.9+, wanted-1.9 bugs auto-approved. Other > changes require explicit approval flags > Tree Control Level 2/Orange: 1.9+ bugs auto-approved. Other changes > require explicit approval flags > Tree Control Level 3/Red: all check-ins require explicit approval flags > prior to check-in
What about blocking-firefox3+ bugs? And if in general they are auto-approved, what if the fix touches core code?
Mike Schroepfer wrote: > Tree Control Level 0/Green: Open tree. Checkin after r+/sr+ only > Tree Control Level 1/Yellow: 1.9+, wanted-1.9 bugs auto-approved. Other > changes require explicit approval flags
None of these levels mention exemption for browser/frontend work, but several people on #developers have assumed that FE work was exempted from the approval requirement. What is intended?
>> Tree Control Level 0/Green: Open tree. Checkin after r+/sr+ only >> Tree Control Level 1/Yellow: 1.9+, wanted-1.9 bugs auto-approved. Other >> changes require explicit approval flags
> None of these levels mention exemption for browser/frontend work, but > several people on #developers have assumed that FE work was exempted from > the approval requirement. What is intended?
Benjamin Smedberg wrote: > Since the rules posted by mconnor and schrep do not agree, which set of > rules are we following?
I personally took stating 1.9 approval by schrep as meaning core since we've discussed this to some extent in the FF 3 planning meetings though that could as easily be toolkit since we use essentially the same flag.
schrep / mconnor - could you answer whether browser / toolkit patches are subject to the Branch Planning Approvals post by schrep?
>> After M7: we'll re-enter Yellow as planned. >> Two weeks before M8: we'll enter Red
> Why red, instead of orange? Locking down checkins for blocker bugs this > early in the game (pre-beta) seems excessive. Going to a "red" scheme a few > days before release seems reasonable to avoid introducing instability/delays > right before the beta.
To me it depends on whether M8 is an Alpha or Beta. If it is a beta I'd say I want a longer stabilization period before pushing it to 100-500K users.
> Also, are we explicitly stating that checkins that are not part of the > Firefox default build are exempt from these requirements (this includes > port-specific work for OS/2, photon, etc)?
Yes - should have said that explicitly. Has been is and is still true.
Robert Strong wrote: > Benjamin Smedberg wrote: >> Since the rules posted by mconnor and schrep do not agree, which set of >> rules are we following?
Here's my attempt to reconcile:
Schrep:
After M7: we'll re-enter Yellow as planned. Two weeks before M8: we'll enter Red After M8: we'll re-enter Yellow Two weeks before M9: we'll enter red and stay there for the rest of the release
MConnor:
* Any remaining Gecko features require explicit driver approval.
We are in Gecko feature freeze. So no features should go on the blocker or wanted-1.9 lists.
* All non-feature blockers have blanket approval for checkin. Same as above * All non-feature patches already marked as [wanted-1.9] by drivers also have blanket approval until August 22 (two weeks before M8 freeze). After August 22nd, explicit driver approval will be required for wanted-1.9 patches, although this status will be considered by drivers. Same as above I believe
* All other patches will require explicit approval starting from the tree reopening. Same as above I believe.
> schrep / mconnor - could you answer whether browser / toolkit patches > are subject to the Branch Planning Approvals post by schrep?
No. We had already said browser stays open until the freeze leading up to M8.
So to re-summarize: a) No features should be on the blocking or wanted-1.9 lists... b) Browser/toolkit have ability to land features until the freeze before M8.
Mike Schroepfer wrote: > Benjamin Smedberg wrote: >> Mike Schroepfer wrote:
>>> B) Approval Plan:
>>> After M7: we'll re-enter Yellow as planned. >>> Two weeks before M8: we'll enter Red
>> Why red, instead of orange? Locking down checkins for blocker bugs this >> early in the game (pre-beta) seems excessive. Going to a "red" scheme >> a few >> days before release seems reasonable to avoid introducing >> instability/delays >> right before the beta.
> To me it depends on whether M8 is an Alpha or Beta. If it is a beta I'd > say I want a longer stabilization period before pushing it to 100-500K > users.
Agreed. Also remember that things can land even in red. You just need approval, which you'll likely to get for a blocker with a safe patch. And if the patch is not safe landing it just before a beta release doesn't seem like a good idea.
Mike Schroepfer wrote: > Robert Strong wrote: >> schrep / mconnor - could you answer whether browser / toolkit patches >> are subject to the Branch Planning Approvals post by schrep?
> No. We had already said browser stays open until the freeze leading > up to M8.
> So to re-summarize: > a) No features should be on the blocking or wanted-1.9 lists... > b) Browser/toolkit have ability to land features until the > freeze before M8.
Slight clarification confirmed by schrep: b) Browser/toolkit have ability to land *patches* until the freeze before M8.
Robert Strong wrote: > Mike Schroepfer wrote: >> a) No features should be on the blocking or wanted-1.9 lists... >> b) Browser/toolkit have ability to land features until the >> freeze before M8. > Slight clarification confirmed by schrep: > b) Browser/toolkit have ability to land *patches* until the freeze > before M8.
I don't understand what distinction is being drawn by this clarification.
>>> a) No features should be on the blocking or wanted-1.9 lists... >>> b) Browser/toolkit have ability to land features until the >>> freeze before M8.
>> Slight clarification confirmed by schrep: >> b) Browser/toolkit have ability to land *patches* until the freeze >> before M8.
> I don't understand what distinction is being drawn by this clarification.
So, are all patches directly associated to a feature? I don't think they are but I can see how the argument could be made that they are.
What ever the case, the clarification was to hopefully lessen any confusion on a subject that as schrep put it is clear as mud.
In summary, the approval process for browser and toolkit for M8 is currently the same as it was for M7, etc.
> Here's a short summary of the discussion in the Gecko meeting today:
> A) Definitions (or "Threat Level" as Vlad put it):
> Tree Control Level 0/Green: Open tree. Checkin after r+/sr+ only > Tree Control Level 1/Yellow: 1.9+, wanted-1.9 bugs auto-approved. > Other > changes require explicit approval flags > Tree Control Level 2/Orange: 1.9+ bugs auto-approved. Other changes > require explicit approval flags > Tree Control Level 3/Red: all check-ins require explicit approval > flags > prior to check-in
It's come up that we didn't clarify who would be doing approvals and driver duties during the yellow/orange/red phases.
From schrep's message about branch drivers, it was proposed that the endgame drivers would be (at the start):
I would propose that this group handle approvals during the Orange and Red (active risk mitigation) phases and the area drivers will handle approvals during the yellow (more risk-tolerant) phases. This allows the area drivers to continue to approve useful things, while keeping the risk management phases under control of a smaller group who could meet daily to triage requests.
Mike Schroepfer wrote: > So to re-summarize: > a) No features should be on the blocking or wanted-1.9 lists... > b) Browser/toolkit have ability to land features until the > freeze before M8.
> Clear as mud? :-)
Probably. What about frontend-only stuff that is built in Firefox but not in browser/ or toolkit/ directories, just like my UI text clarifications in https://bugzilla.mozilla.org/show_bug.cgi?id=385458 or similar things? Do we need to go for approvals for such fixes or are we still on the same non-approval path as browser/ and toolkit/ for those?
Mike Connor wrote: > I would propose that this group handle approvals during the Orange and > Red (active risk mitigation) phases and the area drivers will handle > approvals during the yellow (more risk-tolerant) phases. This allows > the area drivers to continue to approve useful things, while keeping the > risk management phases under control of a smaller group who could meet > daily to triage requests.
Is there a way to get a list of these approval requests broken down by group?
> I would propose that this group handle approvals during the Orange and > Red (active risk mitigation) phases and the area drivers will handle > approvals during the yellow (more risk-tolerant) phases. This allows > the area drivers to continue to approve useful things, while keeping the > risk management phases under control of a smaller group who could meet > daily to triage requests.
