Lucid auto-syncing with Debian testing

[Scott Kitterman]

On Sun, 01 Nov 2009 18:45:34 -0800 Robbie Williamson 
<robbie.williamson at canonical.com> wrote:
>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.

I think doko's concerns about blockage due to transition issues  from 
Unstable to Testing are a reasonable consideration.  I think syncing from 
Debian Unstable is fine.  IMO, most of our recent toolchain related 
problems (Python 2.6 in Jaunty and GCC 4.4 in Karmic) were for being newer 
than Debian Unstable.

I wouldn't worry about Lucid +1.  LTS +1 releases are notoriously crackful. 
 A few extra merges won't affect that significantly.

I'm personally quite dissappointed this decision was taken without 
significant community input.  IIRC, this is not what we discussed at the 
LTS/Debian planning session at the last UDS.

Scott K