Settling on Final Freeze Date for Natty

[Kate Stewart]

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.

> 
> > 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? 


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 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!

Kate

> 
> Thanks,
> 
> Martin
>