Today is Branch Day - as previously announced, as of today, we'll be moving development activities for Firefox 3.1 / Gecko 1.9.1 from mozilla-central to the mozilla-1.9.1 repository (located at http://hg.mozilla.org/releases/mozilla-1.9.1/ ). Once we're done, mozilla-central will be used for code intended for the next Gecko release (currently versioned as Gecko 1.9.2 but that number may change) and will be open to a more lax set of check-in rules. The mozilla-1.9.1 repository will be used for Firefox 3.1 builds, and will require that patches either fix blockers or have explicit approval, and have first been checked in and "baked" on the mozilla-central repository. Build & testing infrastructure exists for both trees.
// What's Happening on the Tree Today
The release engineering team will be:
- merging mozilla-central to mozilla-1.9.1, - and migrating the BuildBot master to a machine with faster disks.
All trees (mozilla-central, mozilla-1.9.1 and the Firefox3.0 tree) will be CLOSED until these tasks are complete, as BuildBot will be down. The team expects to be done by 1:00pm PST (21:00 UTC) if not earlier. When done, they will announce in dev.planning that the downtime is complete and will tell #developers to re-open the trees.
/mozilla-central - checkins require proper reviews and should come with tests for any new or modified function - before checking in, make sure that automated unit tests, mochitests and leak tests pass (you can check this locally) - after checking in, the committer *must* watch for regressions and be ready to back out if they appear - checkins must adhere to standard tree rules (see: https://developer.mozilla.org/en/mozilla-central #mozilla-central_tree_rules )
/releases/mozilla-1.9.1 - checkins only allowed if they fix a blocker, have explicit approval, or are not part of the build (NPOTB) - before landing on mozilla-1.9.1, patches must first land on mozilla-central and "bake" there to watch for performance regressions - any string change must be marked with the late-l10n keyword and have explicit approval - any add-on compatibility change must be marked with the late- compat keyword and have explicit approval
// Bugzilla, Tinderbox & Tools
Some Bugzilla behaviour will change after the branch. Bugs should be marked RESOLVED FIXED once they have landed on mozilla-central. After landing on mozilla-1.9.1, the fixed-1.9.1 keyword should be added to the bug.
> /mozilla-central > - checkins require proper reviews and should come with tests for any > new or modified function > - before checking in, make sure that automated unit tests, > mochitests and leak tests pass (you can check this locally) > - after checking in, the committer *must* watch for regressions and > be ready to back out if they appear > - checkins must adhere to standard tree rules (see: https://developer.mozilla.org/en/mozilla-central > #mozilla-central_tree_rules )
> /releases/mozilla-1.9.1 > - checkins only allowed if they fix a blocker, have explicit > approval, or are not part of the build (NPOTB) > - before landing on mozilla-1.9.1, patches must first land on > mozilla-central and "bake" there to watch for performance regressions > - any string change must be marked with the late-l10n keyword and > have explicit approval > - any add-on compatibility change must be marked with the late- > compat keyword and have explicit approval
> // Bugzilla, Tinderbox & Tools
> Some Bugzilla behaviour will change after the branch. Bugs should be > marked RESOLVED FIXED once they have landed on mozilla-central. > After landing on mozilla-1.9.1, the fixed-1.9.1 keyword should be > added to the bug.
How should we approach sheriffing here? Sheriffs right now watch mozilla-central, and branch drivers watch the branch trees. In the build up to Firefox 3, sheriffs watched CVS trunk while new development was happening on hg, which made the "branching" less obvious.
Given that Firefox 3.1 is the next release, the one that is locking down, the one where perf/test regressions are the most threat to schedule and release planning, it feels like it's the obvious tree to be sheriffing. Obviously sheriffs and other interested parties will still be looking at trunk, particularly in its role as patch-baker, but I think asking sheriffs to manage both trees is a tall order.
In any event, for a long time the sheriffs have been watching the tinderbox called "Firefox" so if we want them focusing on "Firefox3.1" we should make that clear. We should also make it clear on the "Firefox" tinderbox that the tree is unsheriffed. I'm happy to make those changes to the tree messages, I just want to make sure we agree on the approach.
Cheers,
Johnathan
--- Johnathan Nightingale Human Shield john...@mozilla.com
Johnathan Nightingale wrote: > How should we approach sheriffing here? Sheriffs right now watch > mozilla-central, and branch drivers watch the branch trees. In the > build up to Firefox 3, sheriffs watched CVS trunk while new development > was happening on hg, which made the "branching" less obvious.
That was because the hg repos tinderboxes were completely broken until we applied all our collective energy to them... there was nothing useful to watch.
> Given that Firefox 3.1 is the next release, the one that is locking > down, the one where perf/test regressions are the most threat to > schedule and release planning, it feels like it's the obvious tree to be > sheriffing. Obviously sheriffs and other interested parties will still > be looking at trunk, particularly in its role as patch-baker, but I > think asking sheriffs to manage both trees is a tall order.
I definitely think we ought to have an active sheriff for -central: we can't afford a free-for-all with performance or other regressions with no coordinator.
We probably ought also to have a sheriff for -1.9.1: there are enough patches landing that asking the release drivers to do it is not going to work.
I think that we should try to have the sheriff of the day be responsible for both trees and see how that works. If you're sherriff, your day is already shot to hell with interrupt-driven activity; I think it's unlikely that an additional tree will make it much worse. If it becomes too much work, we can create a separate schedule for the -1.9.1 tree.
* The final mozilla-central -> mozilla-1.9.1 merge was done. * GECKO_1_9_1_BASE tags have been landed in both repositories to indicate the branch point. * mozilla-central has been bumped to 3.2a1pre/1.9.1a2pre
Still to do: * Rebrand mozilla-1.9.1 as Shiretoko * Deploy a Talos patch
Alright folks, RelEng is done with the tree. To summarize, we've done the following: * Updated branding to Shiretoko (thanks Gavin) * Bumped the mozilla-central version number to 3.2a1pre * Added GECKO_1_9_1_BASE tags to indicate branch point * Performed a final merge of mozilla-central -> mozilla-1.9.1
The only thing left to do is perform a final merge of l10n-central -> l10n-mozilla-1.9.1 repositories -- I will be doing this tomorrow morning.
Consider this an official hand-off back to #developers.
And just to wrap it up, the trees are now open. There's no sheriff until tomorrow morning when Ryan takes over, so please make sure that if you commit a patch, you watch for performance regressions carefully using the tools at hand (both Tinderbox pages link to graphs and dashboards).
> Alright folks, RelEng is done with the tree. To summarize, we've > done the following: > * Updated branding to Shiretoko (thanks Gavin) > * Bumped the mozilla-central version number to 3.2a1pre > * Added GECKO_1_9_1_BASE tags to indicate branch point > * Performed a final merge of mozilla-central -> mozilla-1.9.1
> The only thing left to do is perform a final merge of l10n-central - > > l10n-mozilla-1.9.1 repositories -- I will be doing this tomorrow > morning.
> Consider this an official hand-off back to #developers. > _______________________________________________ > dev-planning mailing list > dev-plann...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-planning
