Release Team Members: input requested...

Kate Stewart kate.stewart at
Mon Apr 2 21:54:43 UTC 2012

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


More information about the Ubuntu-release mailing list