Lucid auto-syncing with Debian testing

Robbie Williamson robbie.williamson at canonical.com
Mon Nov 2 02:45:34 GMT 2009


For those first hearing of the sync with testing, the schedule was
included in the Lucid Lynx announcement in September:
  http://fridge.ubuntu.com/node/1916
and while it has undergone some changes since the announcement, the sync
from Debian testing as been there the entire time. With that said, I'm
sorry we have not announced in u-d-a yet, and I promise to do this as
soon as possible this week.  

With our decision to merge from testing for the LTS (to reduce the
number of regressions and bugs normally introduced when we sync from
unstable), I've struggled with the DIF date during this cycle. In
practice, the Debian freeze policy means that we would be getting lots
of added bugfix goodness, so a later than usual freeze is acceptable in
that it would end up at exactly the time we want to be in bugfixing
mode.  Ideally, the earlier in our cycle Debian freezes the more
stabilization benefits we get by autosyncing from testing.  We would
want to allow for at least a couple of weeks of continued autosyncing
from testing (*after* testing is frozen) to let us shake off the results
of Debian developers' last-minute-before-the-freeze uploads. 

However, with Debian announcing their freeze in *March*, we are faced
with a situation of getting hit with these last-minute-before-the-freeze
uploads without sufficient time to recover before release.  So now we
need to shut down autosyncing *before* we start accumulating these
last-minute uploads.  With only a month provided by the Debian Release
Team for their freeze (i.e. no day or week), what is an acceptable
buffer? After speaking with slangasek, we originally decided to put in
early February, but then I became a bit concerned last week that it was
too late in the cycle and moved it to January.  In hindsight, this was
done in haste and I've moved it back to the week of Feb 11th.  

I understand the concern of the Lucid+1 release containing a deluge of
merges and being a "shock" to developers (and users). One way to handle
this issue is to start merges 2 weeks *before* the release of Lucid in a
PPA(s) (week of April 15th), and then move these over once the Lucid+1
release opens up in Launchpad (since we cannot have more than one open
at a time).

We are in some uncharted waters with this new LTS schedule, and thus
will no doubt make some mistakes early on. I again, apologize for not
making more noise about this earlier on, this was not the plan. It
simply fell down in my list of priorities during Karmic as some things
heated up late in the cycle (e.g. boot "fun" in Alpha 6/Beta). I would
like to point out that all of these changes are geared towards trying to
meet the needs and expectations that we've received from LTS users,
while still keeping the release as "shiny and new" as possible...which
isn't easy.

Thanks,
Robbie

-- 
Robbie Williamson                      twitter/identi.ca: undacuvabrutha
Ubuntu Foundations & Security Team Manager     robbiew[irc.freenode.net]
http://wiki.ubuntu.com                                 robbie at ubuntu.com

"You can't be lucky all the time, but you can be smart everyday" 
 -Mos Def

"Arrogance is thinking you are better than everyone else, while
Confidence is knowing no one else is better than you." -Me ;)
                                     




More information about the ubuntu-devel mailing list