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
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
> 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
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?
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
There's a [wanted-1.9] status whiteboard annotation.
-Boris
What about blocking-firefox3+ bugs? And if in general they are
auto-approved, what if the fix touches core code?
> 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
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Since the rules posted by mconnor and schrep do not agree, which set of
rules are we following?
--BDS
schrep / mconnor - could you answer whether browser / toolkit patches
are subject to the Branch Planning Approvals post by schrep?
Robert
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.
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
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
I don't understand what distinction is being drawn by this clarification.
Dan
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
> 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
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
> 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
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