Lucid auto-syncing with Debian testing

[Jordan Mantha]

On Sun, Nov 1, 2009 at 9:45 PM, 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.

But it was never mentioned in the actual announcement. It is a pretty
dramatic change and I would think one that would get more general
discussion, not just an announcement.

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

How was it determined that using testing as a merge/sync base would
reduce the number of regressions or bugs? It is not clear to me at all
that it would necessarily follow. Ubuntu has had a history of using
packages from Debian experimental or not yet even in Debian at all.
This seems like a bit of an over-reaction to try to make the LTS
release more stable, but we haven't seen an argument for  why using
Debian testing as a sync/merge base will in fact produce a better
Ubuntu release.

I've seen many cases where we gained an awful lot by getting the
latest Debian version and I've seen packages get hung up from going to
testing for things that would really not effect an Ubuntu release or
would be easily fixable in Ubuntu.

My concern is that one of the major complaints leveled against Ubuntu
is that it fails to incorporate fixes from upstreams because it is so
far downstream. Basing off of testing would seem to me to make that
problem worse. It also adds an extra level of checking that Ubuntu
developers need to do: "I better check to see if I should request a
sync from unstable instead, there might be newer patches".

<snip>
> 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.

A few questions:
1) why go into uncharted waters with an LTS? it seems the opposite of
what you're trying to accomplish
2) why are you determining the development cycle? (I mean this in the
sense of, shouldn't that load be spread around among the team leaders
and the Technical Board?)
3) who's the "we" in "we've received from LTS users"? Are these needs
and expectations written down somewhere? It would be nice if all
Ubuntu developers were on the same page and reading from the same play
book.