Position Summary: Dapper Drake Release Management

This is not a firm position statement, just a summary of what I think
are the key ideas to emerge from the discussion so far on the Dapper
release process.

Let me clarify some of our goals with Dapper.

 First, in the battle between "latest shiny features" and "enterprise
class solid as a rock", we must recognise the user expectation that
Ubuntu will ship a new release with the latest desktop tools. Partly,
that's driven by the fact that the free software desktop is changing
very quickly now that it is a real focus of upstream development, and so
new releases bring substantially better features and performance that
are important to users.

 So I think I can commit that Dapper will have Gnome 2.14 and KDE 3.5
(but I'm less certain of the KDE release position at this time). Now, we
don't influence the Gnome release timing. If we want to add more
stability to Gnome 2.14, we need to give ourselves some time to do so.
The current best practice of Ubuntu releases is to time them for Gnome
2.x.1 + 1 week. If we were to give more time post Gnome-2.x.1 we would
be able to clean up any last-minute issues. At the same time, however,
there's a certain social frustration that bulds up when people can't
work on the latest greatest stuff. So I think it would be risky to push
out more than an extra week or two. That means we are likely to release
Dapper at Gnome 2.14.1 + 2-3 weeks.

 Second, there's the question of syncing and UVF. Having listened to the
debate I'm leaning to the camp that says that the major breakages we
experience are all tied to feature goals, hardware (kernel), and X,
which will all get revved in any event. I am therefor strongly in favour
of syncing from Debian and upstream for the first few months of Dapper's
existence, rather than continuing on the "core" of Breezy. I think we
will get as many  bug fixes as new bugs, and we will ultimately get a
better platform.

That said, we have different goals for Dapper, and so we will have to DO
something different if we want to deliver on those goals. I am leaning
towards the idea that we create more time for polish pre-preview by
freezing upstream version syncing a little earlier than usual. So that
suggests that the cycle will look familiar, we will just have UVF a few
weeks earlier, and the actual release a little later.

Now, the big question that this thread hasn't addressed has been the
amount of work we try to put into new features. There were a LOT fo
goals for Breezy, many delivered, many partially completed, some
deferred entirely. It is going to be important that we prioritise and
set tightly defined and managed goals for Dapper, so that we balance the
enrgy that goes into new features with the energy we put into polish.
It's not just stabilisation that will make Dapper rock - it's lots of
polish in easy-to-find but time consuming-to-execute places that will
make people think "wow, this raises the bar in the Just Works (tm) game".