Fwd: Proposal to move Merge Day one day earlier
mbanner at mozilla.com
Mon May 21 11:24:57 UTC 2012
I just wanted to highlight this on mozilla.dev.planning in case folks
hadn't see it. I've not thought of any objections from the comm-*
central point of view, so unless anyone else comes up with anything, I
strongly expect this to be going ahead from the next merge point.
-------- Original Message --------
Subject: Proposal to move Merge Day one day earlier
Date: Wed, 16 May 2012 09:35:31 -0700
From: Lukas Blakk <lsblakk at mozilla.com>
To: dev-planning at lists.mozilla.org
tl;dr Unless there are any blocking issues brought up about this
proposal the merging and uplifting of our release repos will take place
the day before the next release,*Monday June 4th.*
After doing some investigation, it turns out there is no technical
reason to keep merge day mechanicstied to release datesof Firefox.
In order to lessen the amount of infra churn and decrease the potential
for error on release days, Release Management is proposing moving the
merging of release repos (central -> aurora -> beta) to the day before
release days. Thiswill typically fall on a Monday unless a release day
is ever shifted from its current Tuesday spot.
What will this mean for developers?
* Aurora updates will be throttled one day earlier to avoid picking up
the new nightlies that are kicked off post-merge
* Nightly/Aurora landing cut off will be one day earlier
* In the case of a Beta respin post-merge, landings will have to be done
in two places: on a mozilla-beta relbranch and to the mozilla-release repo
* There will be a day where marking your bug fixed will require
additional thought about what version number the fix landed on
Again, there is nothing lost technically in the moving of merge day. We
can still build last-minute betas if we need to respin, and we will have
an opportunity to QA the new nightlies post-merge ahead of release day
so this move should make the whole process smoother over two days
instead of one.
Release Manager, Mozillian
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning