Tree Logistics: Branching, Migrating & New Checkin Rules, oh my!
Mike Beltzner
(reply-to: dev-pl...@lists.mozilla.org)
Hey everyone,
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.
// Check-in rules when the tree re-opens
(note: for easy reference, you can always find the check-in rules for
any tree at https://wiki.mozilla.org/TreeStatus )
/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.
Tinderbox and Talos have been set up for the new mozilla-1.9.1 branch;
you can see the build waterfall at http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox3.1
A new performance monitoriing dashboard exists at http://people.mozilla.org/~johnath/pdb2/
- by default it monitors mozilla-1.9.1
// That's it!
Please feel free to ask any questions, or suggest where existing
documentation should be updated.
cheers,
mike
Johnathan Nightingale
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
joh...@mozilla.com
Benjamin Smedberg
> 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.
--BDS
Ben Hearsum
* 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
Ben Hearsum
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.
Mike Beltzner
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).
If you need a reminder, the rules for the trees are at http://wiki.mozilla.org/TreeStatus
cheers,
mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning