Branch Planning, Approvals, Threat Levels, and you!
Mike Schroepfer
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.
Best,
Schrep
Axel Hecht
> Hey Folks,
>
> 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.
Axel
Benjamin Smedberg
> 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.
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.
--BDS
T Rowley
> Tree Control Level 1/Yellow: 1.9+, wanted-1.9 bugs auto-approved. Other
> changes require explicit approval flags
There appears to be no "wanted-1.9" flag - just "blocking1.9". Are we
waiting for a new flag to be added, or did you mean the latter?
Boris Zbarsky
> 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.
-Borsi
Boris Zbarsky
> There appears to be no "wanted-1.9" flag - just "blocking1.9".
There's a [wanted-1.9] status whiteboard annotation.
-Boris
Simon Montagu
> Hey Folks,
>
> 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?
Benjamin Smedberg
> 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?
--BDS
Robert Strong
a good idea to restate it.
-Robert
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Benjamin Smedberg
> The M8 Checkin Rules post by mconnor covered this though it sounds like
> a good idea to restate it.
>
> http://tinyurl.com/29yzfp
Since the rules posted by mconnor and schrep do not agree, which set of
rules are we following?
--BDS
Robert Strong
> Since the rules posted by mconnor and schrep do not agree, which set of
> rules are we following?
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?
Robert
Mike Schroepfer
> 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.
> 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.
Mike Schroepfer
Mike Schroepfer
> 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.
Clear as mud? :-)
Schrep
Jonas Sicking
> 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.
/ Jonas
Robert Strong
> 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.
b) Browser/toolkit have ability to land *patches* until the freeze
before M8.
Dan Mosedale
> 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.
Dan
Robert Strong
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.
Robert
Mike Connor
On 1-Aug-07, at 10:58 PM, Mike Schroepfer wrote:
> Hey Folks,
>
> 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):
MConnor, CBeard, Beltzner, Basil, Schrep, Damon, Vlad
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.
Does that make sense?
-- Mike
Robert Kaiser
> 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?
Robert Kaiser
Benjamin Smedberg
> 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?
--BDS
T Rowley
> From schrep's message about branch drivers, it was proposed that the
> endgame drivers would be (at the start):
>
> MConnor, CBeard, Beltzner, Basil, Schrep, Damon, Vlad
>
> 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.
>
> Does that make sense?
Who are the "area drivers"? The module owners?
Boris Zbarsky
> Who are the "area drivers"? The module owners?
The people who've been triaging the blocking1.9 nominations. See
<http://wiki.mozilla.org/Firefox3/Drivers>.
-Boris