Release Team Members: input requested...

Mon Apr 2 22:17:47 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/02/2012 05:54 PM, Kate Stewart wrote:
> Dear Release Team members, Thank you for your excellent work in
> getting our Beta 2 out the door! :)  The use of -proposed for the
> first time was very cool to see in action and made the Unity and
> late Kernel changes go a lot smoother than they would have
> otherwise.  The new queue bot was very useful at keeping down the
> adrenaline as well.  :)
> 
> Now that Beta 2 is out, and we're entering the last stretch before 
> we put out the 12.04 LTS[1],  there are a couple of things we need
> to figure out for the remainder of the month,  especially on how we
> want to be managing the archive frozen period, and -proposed.  A
> goal for this release is to have the image we produce at the start
> of the release candidate window be a true release candidate, and
> any images from final freeze on be potentially shippable.  The
> schedules were earlier aligned to permit this, now its time to
> figure out rest of details...
> 
> For the past 2 releases[2][3], we've kept the archive frozen after 
> Beta 2 went out, until Final Freeze[4].  This time we've got two
> weeks until now and the Final freeze,  so keeping it frozen and
> asking for review of all the bug fixes, etc. throughout would be a
> lot of work.  On the other hand,  if we want to be able to have
> TRUE release candidate image, a week before release,  we need to
> start the hard choices about what fixes go in, and which ones go to
> SRUs,  before the Final Freeze[4], based on past experiences.    We
> also now have -proposed to leverage here, and experiment with as
> part of this.
> 
> To mitigate risk, and make effective use of the release team's
> review cycles,  I'd like to propose we try out the following for
> any packages in our seeded images (main+universe):
> 
> now-4/5 - Archive stays open to bug fixes and approved FFes only. 
> 4/5 - KernelFreeze[5],  and archive goes into pre-release freeze 
> state at 2100.  Release team reviews all patches targetted to
> -release.  SRUs can start to go into -proposed, and get reviewed at
> discretion of release team for opportunity inclusion into
> -release. 4/12 - Final Freeze[1] - ALL fixes should go into
> -proposed,  and only copied into -release after review meeting.
> Full QA ISO testing run done at start, to identify problem cases. 
> Release team meets daily for 1/2 hour at 1600 GMT in 
> #ubuntu-release to figure out which fixes we want to include in
> overnight images,  and determine who is best match for reviewing
> them for risk/upside, and copy vs. rebuild into -release.  There
> should be no fixes being added, unless its a fix that a member of
> the release team specifically requests.  Images continue to be
> built daily.    All packages should be reviewed and built by 2300
> GMT in -release, so they can be included in the nightly builds. 
> 4/19 - CandidateWindowStarts[6] - from this point forward, any of 
> images produced could be the final one.  CRON job is disabled. The
> full set of QA results needs to be gathered on these images.
> Continue with daily release team meetings to agree if any
> additional fixes in -proposed MUST be included,  and let QA teams
> know explicitly if another round of full manual testing is going to
> be needed. 4/26 - Ship it.
> 
> Does this seem like a reasonable way to leverage -proposed?  spread
> the release team review work to where it matters most and still
> accomplish goal?   alternatives?
> 
> Also, for those packages that are in unseeded universe,  FFes and
> fixes will continue to be reviewed and accepted into -release until
> the FinalUnseededUniverseFreeze at April 24 at 0900 UTC (per
> earlier discussions [1].     Iain, Stefan, Stefano, Scott, Iulian -
> will one of you volunteer to be the focal point contact?   Am
> assuming you all be using #ubuntu-motu to discuss/monitor unseeded
> universe during the time from when the archive freezes?   Is this
> correct?
> 
> Any other questions/issues/thoughts on the upcoming month?   If
> the above seems reasonable I'll start updating the checklists[8] to
> reflect this, and working with the other teams to get us all
> coordinated.
> 
> Thanks, Kate
> 
> 
> [1] https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule [2]
> https://wiki.ubuntu.com/OneiricReleaseSchedule [3]
> https://wiki.ubuntu.com/NattyReleaseSchedule [4]
> https://wiki.ubuntu.com/FinalFreeze [5]
> https://wiki.ubuntu.com/KernelFreeze [6]
> https://wiki.ubuntu.com/CandidateWindowStarts [7]
> https://wiki.ubuntu.com/UnseededUniverseFinalFreeze [8]
> https://wiki.ubuntu.com/ReleaseCandidateProcess

Sounds good, +1 here

The only problem I can see with the above is the potential confusion
between -proposed used as staging for -updates and for -release at the
same time.

It's not impossible we could get a case where we have a package in
- -proposed waiting to enter -updates (0-day SRU) but also have another
update for the same package that's critical for release landing in
- -release. We'd then need to remove the one from -proposed and ask for
re-upload to include the changes from the one in -release.
That or also push the SRU in the upload to -release (if it's
considered safe).

So yeah, might cause a bit of confusion but that's for a few corner
cases that we hopefully won't hit and even if we do, it's possible to
deal with them, just might look a bit weird ;)

- -- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPeiWLAAoJEMY4l01keS1n4/IP/32bDIgvEtg/eqLRTXAqJPEu
6daUe/4JCRBsmdQ/Y3VKeDr9YZKLMastyRW3IyIwsqh1MbxvVETHsdvy7TPc0V36
mPpLZdKih7l66WJaWGclMtpEkEUoRZ3/8II9px4f2uV3c9Y2FX7bX/Us3R7hev9u
3Ut92TjlMytLG0RVpB34iObSP4ScISP/flDSpHNu7jpXDy6ETZhHbMZqV4d/HAe+
KmIz9iuKkadp/6mbzgIJphZva5c7MCs2ZABQwj1DJGw4wsHzQp/BD3OIq8Qd1CGT
il+BUtej46i8kK1ha+G/4R7INliIAPe4gKcNqAKK/5F4doj0TqTFtciW106wmRNH
wm7dCOqOBhCkdQnywZz1856mzbkIcJWBV06Q/VRtJTAVL2PtfUfXMZKyxGAEIkM7
EgxjAf/9Pb/Nevajz1Q76OIPx05FJfGszbq0S+Cs9LAkVTM7rPBEnitelyNzbu41
q4inH3s4LnCONAyVbwjxApPN+iNBIesBra3a1LsWckHv3wxtNM64NwUt1bmRHNIV
2Tudk/PZV688uRUqRckF2IoEi+y6W2LQYqMIW/TQblnsoDnA0uWhTrUkPZvySShu
tV/I3JL4+JxFl496NPe+2kkHuLBo9kADv5vvaf4690buMqYcaPndlBYToOX3gt+R
ZgfyWAaYSr846b+o+tIf
=CBmv
-----END PGP SIGNATURE-----