Position Summary: Dapper Drake Release Management

On Tue, Oct 18, 2005 at 02:00:01AM +0200, Jeff Waugh wrote:
> <quote who="Mark Shuttleworth">
> > 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.
> 
> Major breakages are indeed tied to feature goals. Subtle breakage that we're
> not keenly aware of is far more likely to arrive through unchecked changes
> synchronised with Debian sid.

As a slight variation on the earlier "unrestricted manual syncing"
suggestion I made yesterday on IRC, how about treating syncs the way we
treat merges? That is, for main, they're a job that developers have to
do before UVF, so we don't lose out on syncing bug fixes because our own
testing didn't expose them, but developers would still have to approve
the syncs so we don't get totally unreviewed changes arriving
automatically.

> Getting 'as many bug fixes as new bugs' is not good enough for dapper
> - we won't be able to share bug exposure with breezy, we'll have to
> spend more time testing instead of concentrating on merging bug fixes
> only.

It's not quite that simple, because while we lose some shared bug
exposure with breezy, we gain shared bug exposure with the rest of the
world; and while it's harder to be precise about the effect a bug found
somewhere else has on Ubuntu, there's a lot more of the "somewhere
else".

> But this is not so much about avoiding the major punch-in-the-face breakage
> of our feature goal work, more about the stuff we don't see until it's too
> late (that is, end user deployment time).

Which is precisely why it's important for us to take advantage of other
people's end-user deployment work as well as our own. We *are* going to
be changing low-level things that I confidently predict *will* affect
the desktop in unforeseen ways (like, oh, say, the kernel), so just the
end-user feedback from breezy isn't going to be anywhere near enough
anyway. Clinging to breezy's roof is only safe if we aren't ripping away
breezy's foundations and replacing them with new ones. :-)

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]