Settling on Final Freeze Date for Natty

[Scott Kitterman]

On Monday, March 21, 2011 07:31:24 pm Kate Stewart wrote:
> Moving this discussion to ubuntu-release, so release team members
> can see each other's responses.   (using launchpad's ubuntu-release
> didn't have the effect I was looking for, when I sent out the initial
> note).
> 
> Have checked Martin is ok with his responses being posted to this wider
> forum, so, let the thread continue here.  ;)
> 
> On Wed, 2011-03-09 at 15:00 +0100, Martin Pitt wrote:
> > Hey Kate,
> > 
> > CC'ing Colin as well.
> > 
> > Kate Stewart [2011-03-07 20:34 -0000]:
> > > In https://wiki.ubuntu.com/NattyReleaseSchedule ,
> > > having Final Freeze on the same day as Beta 2 doesn't make sense.
> > 
> > Indeed, this should be moved closer to the actual release. Also, I
> > think the "ReleaseCandidate" should go, or do you actually plan to
> > having this in addition?
> 
> ReleaseCandidate has been effectively replace by the Beta 2 for this
> release,  however we'll be spinning the "proposed release images" and
> need some sort of way to refer to them.   Sorry for not being clearer.

How about Proposed Final Release images?

> > > Beta 2 Release 4/14
> > > Kernel Freeze 4/14  (can be earlier)
> > > Final Freeze 4/19
> > 
> > As this is still 9 days to go until the release, this would be a
> > freeze in the sense of "we (tightly) control what's going in still",
> > with the days between b2 and final freeze bein in normal "open
> > archive" feature freeze mode?
> 
> Hmm, probably should clarify what's being advocated for the archive
> before beta 2 as well...
> 
> Between 4/1 and 4/10, we stay in open archive feature freeze mode (bug
> fixes only).
> 
> Between 4/11 and 4/14, we go into beta freeze, tight control of which
> bug fixes go in so we can get the beta 2 images out.
> 
> Between 4/15 and 4/19, we stay in open archive feature freeze mode (bug
> fixes only)
> 
> Between 4/19 and 4/21 - access will be very tightly controlled, and each
> bug fix will need to have review and assessment it won't make things
> worse.
> 
> Last bug fix accepted at 0900 UTC on 4/21,  images start building.
> 
> >From 4/21 onwards, no changes to main except the kitten killers that we
> 
> can't document around, get to go in.  With 4/22 and 4/25 as holidays, I
> don't want us planning for people to have to be working then (if there
> are kitten killers, we may need to, but lets try to avoid it).
> 
> In terms of hard freezing the Universe, my preference would be to freeze
> that too on 4/21 - but would like the MOTU experts to weigh in on when
> we should set this...  ScottK,  Iulian?

For a release on the 28th, I'd leave unseeded Universe/Multiverse open for 
uploads (we'll just push them through the queue as needed) until 1200 UTC on 
25 April.  Hard freeze (all uploads reviewed/approved for appropriateness by 
the release team) between 1200 UTC on the 25th and 1200 UTC on the 26th.  That 
leaves 12 hours, up to the end of the 26th, for discovery and correction of 
any OMGWTFBBQ issues and then 24 hours for mirror sync, Robbiew wants to 
respin, etc and then we should be in good shape at 0001 on the 28th.

> 
> Any factors I've overlooked?
> 
> > I don't think this should be a hard freeze. It'd be even longer than
> > the usual RC->Final freeze, and even that was too long for "no changes
> > at all".
> 
> Problem is that its not really 9 working days.  Does the above proposal
> seem workable?
> 
> > > Release Candidate built 4/21
> 
> I need another term than Candidate here I think ;) , due to the existing
> process around ReleaseCandidate.   "Proposed Release image" seem like a
> better term?  other ideas are welcome.  ;)

I came up with Proposed Final Image before I read down this far (I'd leave the 
word release out of it until it's released).

> > I don't think it makes sense to go through a full validation cycle
> > again at this point, just one week after b2.
> > 
> > However, on that day it would make sense to ensure that all images on
> > that day build and are within size, and that there are no
> > uninstallables/NBS/component-mismatches any more, so that from then on
> > the dailies are all releasable.
> 
> Would actually like the full validation to start off on 4/21 (iso
> tracker, etc.) so if there is an issue, we can get right on it on 4/26
> (if it doesn't get resolved over the easter weekend by someone.)
> 
> Certainly getting all the automated testing running (desktop, server,
> boot times,  hardware cert sniff) in addition to what you call out above
> should happen on 4/21.
> 
> Reasoning is if the QA team starts a sniff test off on a couple of the
> Ubuntu images as soon as they emerge (other flavors are welcome to get a
> head start on their images as well - esp if they think there may be
> something nasty lurking for them), before breaking for good friday, then
> we have a recovery path.
> 
> Testing starting on 4/26 doesn't give us any recovery time if there is a
> kitten killer, since it takes at least a day to do full validation on
> the images, on top of the time to manually get each image generated and
> moved to the iso tracker.   Ideally, we will be able to release the 4/21
> images and not require a respin on 4/26, but rather just finish of the
> testing, documentation/release notes, iso packaging.
> 
> > > Kitten killer respin ( if needed ) on 4/26
> > > 10.04 release on 4/28
> > 
> > We'd do the final release iteration on 4/26 and 4/27 then?
> 
> Hopefully we won't have to and the 4/21 images are good to ship, but if
> we can, then on 4/26 images will go to iso tracker, full validation
> starts when they emerge, and we work late nights that week.
> 
> Thanks for the good questions!

As I understand it, the proposed sequence is:

Beta 1 7 days hard freeze
Open 10 days
Beta 2 4 days hard freeze
Open 4 days
Release 7 days (of which 4 are holiday/weekend)

I think unfreezing the archive between the Beta 2 freeze and the Release 
Freeze is risky, particularly with the short (working days) period between the 
release freeze and the release date.  Each freeze period gets shorter as we 
iterate and I think that's the wrong direction for a smooth release.

My recommendation would be to adjust this slightly:

Defer Beta 1 freeze to Monday 28 March, Freeze for Beta 2 on Monday 11 April, 
and don't thaw the archive between Beta 2 and Final.  That last point will 
make it possible for the release team to know what's changing between Beta 2 
and Final.  That would look like:

+3 Development days before Beta 1 freeze
Beta 1 4 Days hard freeze
Open 10 Days
Beta 2 4 Days hard freeze
Final Freeze 14 Days

That gives about the same number of archive open days and should make it easy 
to get a softer landing jumping from Beta 2 to Final (minimize the risk of 
having to drag people to work on a holiday and mitigate the risk of unexpected 
changes cause problmes between Beta 2 and Final).

Scott K