* have appropriate reviews,
* include tests,
* be fixing a bug marked as blocking-firefox3.1+ or
blocking1.9.1+ or be one of the metered checkins that didn’t get to
land yesterday due to delays from test and build failures.
The tree will be held closed until at least Tuesday of next week as
the Firefox 3.1 and Gecko 1.9.1 teams fix regressions and polish
things up for the beta. At that point we will branch for release and
return the mozilla-central tree to normal sheriff control while we
enforce stricter controls on the Firefox 3.1/Gecko 1.9.1 branch. The
exact branching mechanism is to be decided - watch
mozilla.dev.planning for discussion.
In the meantime, everyone interested in helping can grab a nightly and
look for any regressions or problems with new features. Nominate your
bugs for blocking if you feel they should block release. You can also
track the progress of the release online at http://wiki.mozilla.org/Releases
. If you have questions about the release process or progress, please
ask in mozilla.dev.planning or #shiretoko on irc.mozilla.org.
(this post is also online at https://developer.mozilla.org/devnews/index.php/2008/11/05/tree-now-closed-for-firefox-31-beta-2/
)
cheers,
mike
Whoa. When did we decide to cut the release branch this early? There's
still a fair amount of serious core work that needs to happen for 1.9.1
to fix some of the blockers, and merging it across two branches (esp. if
m-c has fast-moving sweeping changes) could be a major productivity drag...
Also, what will the checkin policy be for the 1.9.1 branch? Presumably
driver approval, but doesn't have to be a blocker, necessarily?
-Boris
Are "not part of the build" changes such as tests part of this closure?
Can we still land npotb changes after coordinating with the sheriff?
> Mike Beltzner wrote:
>> The tree will be held closed until at least Tuesday of next week as
>> the Firefox 3.1 and Gecko 1.9.1 teams fix regressions and polish
>> things up for the beta. At that point we will branch for release
>> and return the mozilla-central tree to normal sheriff control while
>> we enforce stricter controls on the Firefox 3.1/Gecko 1.9.1 branch.
>> The exact branching mechanism is to be decided - watch
>> mozilla.dev.planning for discussion.
>
> Whoa. When did we decide to cut the release branch this early?
> There's still a fair amount of serious core work that needs to
> happen for 1.9.1 to fix some of the blockers, and merging it across
> two branches (esp. if m-c has fast-moving sweeping changes) could be
> a major productivity drag...
The decision was made at the Tuesday development call, but I think we
have proven (and continue to do so) that such changes are not
irrevocable if new evidence is brought to bear. I'll start a thread
immediately about branching strategy and tree control for post-beta 2
so we can confirm the content of those Tuesday calls and get feedback.
> Also, what will the checkin policy be for the 1.9.1 branch?
> Presumably driver approval, but doesn't have to be a blocker,
> necessarily?
>
This'll be in the aforementioned soon to be started thread, but it'll
be:
- patches on blockers, or
- patches with driver approval
For driver approval a risk/reward statement will need to be included.
cheers,
mike
NPOTB/tests are, as always, exempt from the closure. Yay, tests! Be
sure NPOTB is really NPOTB, though. :)
cheers,
mike
When you say "from here on out" do you mean during the freeze period, or
from now until the release of Firefox 3.1?
Until release. Post beta 2 our tree is open to blockers and explicit
driver approvals only.
cheers,
mike
At what point do you intend to create appropriate approval flags?