The Branches That Bind
(Crossposted1 to mozilla.dev.planning, mozilla.dev.builds, mozilla.dev.apps.camino, mozilla.dev.apps.calendar, mozilla.dev.apps.seamonkey, and mozilla.dev.apps.thunderbird).
rhelmer and I have recently been discussing the release process as it relates to tagging and retrieving source from the CVS repository for Firefox and Thunderbird releases.
The way we do it now has a lot of historical vestiges and the policy was crafted around some assumptions that aren't really valid for the project and the way Firefox and Thunderbird (and other projects in the Community) use the repository these days.
So we've come up with the following proposal we'd like feedback on.
The Proposal
When code complete is reached for the current Firefox release milestone, a release branch will be cut. The standard FIREFOX_version_RC1 and _RELEASE tags will be applied, but to a MOZILLA_datespec_RELBRANCH branch that will replace the venerable FIREFOX_version_MINIBRANCH. This _RELBRANCH tag will be applied to the same files the _RC1 and _RELEASE tags have traditionally been applied to.
If respins during the release are required, developers would check the fixes into the relevant (1.8/1.8.0) branches, as always; they could then either check the code into the _RELBRANCH themselves, or we can take care of that, whichever is easier. When the code for the candidate is ready, the next _RCn tag will be applied and the _RELEASE tag will be moved.
Rinse and repeat until the release is shipped.
Any equivalent Thunderbird release (if one is required) will come off of this branch as well. (This is why the suggested name is MOZILLA_datespec_RELBRANCH and not something like FIREFOX_version_BRANCH; products other than Firefox could come off the branch, and versions other than version could come off the branch.)
This branch will then die at the end of the release cycle.
This may be hard to visualize, so I took the liberty of adding it to our beloved branching diagram:2
The Reasoning
Currently, we apply _RCn and _RELEASE tags to the relevant development branch (i.e. MOZILLA_1_8_BRANCH) and then add _RCn tags and move the _RELEASE tag as we respin candidates. This process must be undertaken with extreme care, and while we record information when we perform the operations against the repository, because CVS does not version tag operations, that information is lost to external consumers of the source coming out of CVS (this is why we tag the _RCs individually; to track these changes).
Creating a release branch to isolate and record any changes required for a specific release is a long standing release engineering best practice. In the Mozilla Project's case, it will allow us to record the changes we make during a particular release cycle and isolate changes so that we are able to assert exactly what went into a release.
Additionally, it will make security firedrills significantly easier: the release branch can be revived at any point in time to release a fix to a particular security issue, so we can assert that a particularly release is the previous release with *only* the required security changes, an issue we've run in the past.
Finally, it will (admittedly, for me) simplify the release automation's respin support; the automation can now just track the _RELBRANCH, as opposed to attempting to fake branching by moving tags around on the regular development _BRANCHes.
The Impact
The impact to developers is quite low. In the worst case, those landing post-code complete fixes (fixes to a release candidate) will have to pull a branch to land their changes. In the best case (if a release engineer merges the change, which is TBD, but quite possible), then developers will not be impacted at all.
The impact to other projects relying on the Gecko milestone changes as well as any other consumer of Firefox-related source code should nonexistent; the _RCn and _RELEASE tags will, from an external perspective, still exist and pulling them will do the "expected thing." We have discussed, at some point, forgoing application of the _RELEASE tag until a particular _RC is declared to be the final release, but this would really only impact consumers of the source tarball who pick up the RC tarball.
In terms of the repository, it is the case that one extra tag per release will be applied to all the files; the _MINIBRANCH will be replaced by the _RELBRANCH, so for the four files that were tagged with the _MINIBRANCH, they will have the exact same number of tags.
The Upshot
We're planning on implementing this change for the upcoming Firefox 2.0.0.4 release, so please discuss and let us know if you have any questions or concerns.
______________________________
1 Read: "spammed"
2 Sorry in advance for the unwieldy size.3
3 Click to enlarge!
Comments
Any reason you're using a datespec instead of the expected Gecko revision in your RELBRANCH name? (Or did I miss that explanation?)
IMO, the date is likely to be somewhat meaningless in the long term (and perhaps confusing in both near and long term if there are near-simultaneous RELBRANCHes from, say, different major branches; "what datespec is from what major branch?"), whereas the Gecko revision embedded in a RELBRANCH name should be immediately understandable by all Gecko consumers.
Posted by: Smokey Ardisson | April 19, 2007 10:42 PM
Yeah, the explanation is there, but it's kinda buried and implicit.
I originally thought it'd be a good idea to call it (for instance) the FIREFOX_2_0_0_4_BRANCH; the problem with that is we would release Thunderbird off such a branch as well, hence the suggestion of MOZILLA_.
Then, the reason I chose $datespec instead of version is because it's possible that multiple versions would come off of that branch.
Consider the case where there's a regular release (2.0.0.4); we create a _RELBRANCH, and do the release. Then, a month later, we have a security firedrill, and need to release 2.0.0.4 + 2 security fixes as a 2.0.0.5 release.
Releasing 2.0.0.5 off of something called "MOZILLA_2_0_0_4_BRANCH" didn't seem to make much sense... hence, datespecs.
That's how I arrived at the suggestion, but I'm not married to the branch name; it's just the best thing I could come up with, given the scenarios dictated by the requirements.
Posted by: Preed | April 20, 2007 11:22 AM
I am basking in the ebullience of your MSPaint skills. A hint of late Kandinsky towards the bottom, as the order descends into chaos. Versions grow out from the center, telling of a firm root in eastern philosophy, perhaps recalling the age-old story of yin and yang, yet the fleeting airiness of the composition alludes to a deeper understanding of the inherent chaos that is both humanity and software development. The tree is horizontal, but hasn't fallen, it is merely the perspective that has changed.
It brings me close to tears.
Posted by: Fredrik | April 20, 2007 5:01 PM
MOZILLA_ branches may be conflicting in branch name here, not sure. Not sure if I'd like AVIARY_ better.
Regarding the date vs version, I think we should go for the commonly true version. Releasing a firedrill may look awkward, but I do think that it's better to have a slightly interesting branch nomenclature than to have to look up branching dates somewhere to find out where to go for a particular release branch.
Using versions for branches would also fix the problem with 1.8.0.x not being as dead as we all would wish, and cutting MOZILLA_date_RELBRANCH from two branches doesn't really work that well ;-). In addition, I don't see that coming up as a short-term problem, we might be in a similar position again for Firefox 3 and the 1.8 branch.
Posted by: Axel Hecht | April 23, 2007 7:44 AM
Yeah, I don't like AVIARY_ because unless you've been in the project since 2003 or so, "Aviary" has no meaning ("How did a bird become a fox?")
I don't really like MOZILLA_ either; I thought about FXTB, but... that makes even less sense.
I'll take awkwardness over confusion. It really doesn't make any sense to have a [security firedrill] Firefox 2.0.0.4 come off of something called the MOZILLA_2_0_0_4_RELBRANCH. I'm going to assert that developers won't have to look up branching dates, because for the most part, developers don't have to pay attention to this at all (which is sorta the point; it's an implementation detail that we have to worry about, but not developers, and if they do, we can help them so they don't have to search.)
That is a good point; I'd suggest doing something like SOMETHING_datespec_18RELBRANCH over versions that would make absolutely no sense in a firedrill context, though.
Posted by: Preed | April 23, 2007 8:18 AM
AVIARY_ also isn't an apt tag for non-Fx/Tb consumers of these tags; either you wonder what in the heck we're doing with Gecko 1.7 again (if you've been around long enough) or are totally confused (if you are a "new" arrival to the Mozilla/Gecko ecosystem). Similarly, tying a branch name to Fx version numbers means release engineers (for non-Fx projects; preed and friends will have this down pat) have to track Firefox version numbers rather than the Gecko version they're likely more familiar with and more interested in.
The more I think about it, the more I like the datespec bit, both for the firedrill issue preed mentioned and because a release engineer will just have to query "what's the tag on this branch with the most recent datespec" to get his latest stable Gecko; that's actually less "keeping track of all the crazy versions" than using a Firefox or Gecko version number in the tag. Long-term the datespec tags might still loose some meaning, but it's a good compromise IMO.
Also, if you want to avoid using MOZILLA_ to avoid confusion with the "real" branches, how about GECKO_datespec_18RELBRANCH (since it's all about pulling a stable Gecko, right? ;) )
Posted by: Smokey Ardisson | April 23, 2007 11:02 AM