Post Beta 2 Tree Logistics: mozilla-central & mozilla-1.9.1
Mike Beltzner
mozilla.dev.planning)
Hey everyone,
We're now finished with the Firefox 3.1 Beta 2 freeze, and the build
team is done tagging and bumping the version on mozilla-central to
3.1b3pre. Next Monday morning we'll be moving over to using the
mozilla-1.9.1 repository as the active branch for Firefox 3.1
development. Before then, however, we'll be taking a few days to land
a backlog of blocking and approved patches on the mozilla-central
repository. The following tree rules will apply:
// Now until 17:00 PST Friday, Nov 28th
- mozilla-central will be open only to patches for bugs marked
blocking1.9.1+/blocking-firefox3.1+ or patches with approval1.9.1+
- all patches need to have been compiled & tested locally (run all
tests, ask in #developers if you need help)
- checkins will be metered by https://wiki.mozilla.org/MeteredCheckins
- add your patch to that list; sheriffs will look for people on IRC
first, and land for people if they're not around (to maximize
throughput)
- mozilla-1.9.1 will be kept in sync by a script that will run hourly
(sheriffs can push changes to mozilla-1.9.1 more frequently if wanted)
- any changes that cause oranges or reds will be backed out immediately
// 17:00 PST Friday, Nov 28th to 06:00 PST Monday, Dec 1
- we will do a final merge from mozilla-central to mozilla-1.9.1 (to
be co-ordinated by sdwilsh)
- mozilla-central will be closed to all checkins except for fixes/
backouts to make tinderbox go green
- mozilla-1.9.1 will be kept in sync with mozilla-central
// 06:00 PST Monday, Dec 1 and onwards
- mozilla-central will get a version bump to 3.2a1pre
- mozilla-central will be open to patches with proper review
- mozilla-1.9.1 will be open only to patches for bugs marked
blocking1.9.1+/blocking-firefox3.1+ or patches with approval1.9.1+
- before landing a patch on mozilla-1.9.1 it must first land & bake on
mozilla-central
This will be reflected on Tinderbox and https://wiki.mozilla.org/TreeStatus
cheers,
mike
Axel Hecht
> - mozilla-1.9.1 will be kept in sync with mozilla-central
>
> // 06:00 PST Monday, Dec 1 and onwards
> - mozilla-central will get a version bump to 3.2a1pre
> - mozilla-central will be open to patches with proper review
> - mozilla-1.9.1 will be open only to patches for bugs marked
> blocking1.9.1+/blocking-firefox3.1+ or patches with approval1.9.1+
> - before landing a patch on mozilla-1.9.1 it must first land & bake on
> mozilla-central
What will who do when with the l10n repos?
Axel
Mike Beltzner
> What will who do when with the l10n repos?
That's largely up to you, I think. We will be taking string changes
(though limited - I think we should assert that they all be marked and
require explicit approval) though, so you'll want to open them up
again. We can ask Ben to merge the content from mozilla-central-l10n
repos to the mozilla-1.9.1 repos.
cheers,
mike
John O'Duinn
- turn off hourly script that merges from mozilla-central to mozilla-1.9.1
(Need to do before the version bump lands on mozilla-central.)
tc
John.
=====
> - mozilla-central will get a version bump to 3.2a1pre
> - mozilla-central will be open to patches with proper review
> - mozilla-1.9.1 will be open only to patches for bugs marked
> blocking1.9.1+/blocking-firefox3.1+ or patches with approval1.9.1+
> - before landing a patch on mozilla-1.9.1 it must first land & bake on
> mozilla-central
>
> This will be reflected on Tinderbox and https://wiki.mozilla.org/TreeStatus
>
> cheers,
> mike
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
L. David Baron
> // Now until 17:00 PST Friday, Nov 28th
> - mozilla-central will be open only to patches for bugs marked
> blocking1.9.1+/blocking-firefox3.1+ or patches with approval1.9.1+
> - all patches need to have been compiled & tested locally (run all
> tests, ask in #developers if you need help)
> - checkins will be metered by https://wiki.mozilla.org/MeteredCheckins -
> add your patch to that list; sheriffs will look for people on IRC first,
> and land for people if they're not around (to maximize throughput)
So we've made a bit of progress down
https://wiki.mozilla.org/MeteredCheckins although not as much as I'd
hoped. We were somewhat delayed by a problem with depend builds on
the mac build systems (bug 466399), which should now be fixed
(although nthomas plans to confirm that the fix worked as expected
after the current round of builds complete).
If somebody in a non-Western-US timezone (who knows how to use hg
unbundle and hg merge, and to land mq-formatted patches so that the
checkin comment and user are preserved) wants to take over as
sheriff and continue landing the patches on that list in
mozilla-central, with appropriate separation and watching of
tinderbox, feel free to do so.
(There also seems to be one Linux builder that's currently stuck on
the relbranch that was created this morning; I think nthomas was
planning to look into that as well.)
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Ben Hearsum
> What will who do when with the l10n repos?
>
I'm happy to do this pull && push. We should chat about the specifics,
though.
Axel Hecht
Cool, thanks.
I'll try to chat with folks like sipaq and KaiRo on the specifics, it's
gonna hit their setup, too.
Axel
Robert Kaiser
> // Now until 17:00 PST Friday, Nov 28th
> tests, ask in #developers if you need help)
Does this need to be locally, or is tryserver OK as well?
> // 17:00 PST Friday, Nov 28th to 06:00 PST Monday, Dec 1
> - we will do a final merge from mozilla-central to mozilla-1.9.1 (to be
> co-ordinated by sdwilsh)
> - mozilla-central will be closed to all checkins except for
> fixes/backouts to make tinderbox go green
> - mozilla-1.9.1 will be kept in sync with mozilla-central
Why effectively keep the tree closed to any checkins whatsoever for 2½
days in the period where a lot of our volunteer contributors are most
active (i.e. the weekend)? We're trying to reduce the backlog and build
up another backlog at the end of that timeframe - not ideal, IMHO.
Robert Kaiser
Mike Beltzner
> Mike Beltzner wrote:
>> // Now until 17:00 PST Friday, Nov 28th
>> - all patches need to have been compiled & tested locally (run all
>> tests, ask in #developers if you need help)
>
> Does this need to be locally, or is tryserver OK as well?
AFAIK, tryserver doesn't run unit and mochitests, just performance
tests. So yes, it needs to be locally. More generally, I'm saying that
make sure your patch isn't gonna bust any tests BEFORE you land it in
mozilla-central, as a way of preventing preventable oranges.
>> // 17:00 PST Friday, Nov 28th to 06:00 PST Monday, Dec 1
>> - we will do a final merge from mozilla-central to mozilla-1.9.1
>> (to be
>> co-ordinated by sdwilsh)
>> - mozilla-central will be closed to all checkins except for
>> fixes/backouts to make tinderbox go green
>> - mozilla-1.9.1 will be kept in sync with mozilla-central
>
> Why effectively keep the tree closed to any checkins whatsoever for
> 2½ days in the period where a lot of our volunteer contributors are
> most active (i.e. the weekend)? We're trying to reduce the backlog
> and build up another backlog at the end of that timeframe - not
> ideal, IMHO.
Because there's no sheriff on duty, because we want to do our final
merge after we've had time to make sure we're merging off of a green
tree that's stayed green. Chofmann raised the point that debugging
regressions after a branch is a PITA, so we want to make sure we're in
lock step. I'll be around on Friday, though, and if we work through
the checkin queue on time, maybe we'll get to this point so we can re-
open mozilla-central earlier. TBH, though, I'd rather have a good
baseline of perf data to use for regression hunting.
Do others have opinions, here?
cheers,
mike
Mike Beltzner
>> Why effectively keep the tree closed to any checkins whatsoever for
>> 2½ days in the period where a lot of our volunteer contributors are
>> most active (i.e. the weekend)? We're trying to reduce the backlog
>> and build up another backlog at the end of that timeframe - not
>> ideal, IMHO.
>
> Because there's no sheriff on duty, because we want to do our final
> merge after we've had time to make sure we're merging off of a green
> tree that's stayed green. Chofmann raised the point that debugging
> regressions after a branch is a PITA, so we want to make sure we're
> in lock step. I'll be around on Friday, though, and if we work
> through the checkin queue on time, maybe we'll get to this point so
> we can re-open mozilla-central earlier. TBH, though, I'd rather have
> a good baseline of perf data to use for regression hunting.
We've come up with an even better answer here, again through the
incredible generousness of sdwish's too-good heart.
Tonight, when Shawn finishes being the sheriff, he's going to lock the
tree (using the new tree-locking hook). The tree will bake green (one
hopes) and then tomorrow he's going to spend the day trying to hunt
down some pesky performance regressions that seem to have entered into
our builds, backing things out and watching Talos come up with new
numbers. The tree will then stay locked over Sunday (once again to
bake green and get some baseline numbers against which to compare
things) and then re-open as per plan on Monday after we branch.
cheers,
mike