Release management thoughts for Dapper Drake

[Matt Zimmerman]

On Fri, Oct 14, 2005 at 01:18:11PM +0100, Jeff Waugh wrote:
> I've put a couple of release management ideas to a few people on the team,
> and had a positive response, so now that breezy's "done", I figured it's
> high time I hit the mailing list with them. :-)

I'm surprised you didn't mention them to me earlier...

>  1. Maintain breezy's UpstreamVersionFreeze for main, with exceptions
> 
>     I suggest we maintain breezy's UpstreamVersionFreeze for dapper main, to
>     combine testing exposure and work towards better stability for our long
>     term supported release.

If we go this way, then we miss out on 6 months worth of testing and
stabilization that the Debian and upstream communities carry out (from
Breezy UpstreamVersionFreeze through Dapper UpstreamVersionFreeze).  In
exchange, we get an extra 6 months worth of testing and stabilization in
Ubuntu (Breezy UVF - Dapper final, rather than Dapper UVF - Dapper final).

I don't think that's a winning proposition for us.  Debian and upstream fix
more bugs than we do, hands down, but this is even more true within the set
of packages you're suggesting we keep frozen.

It also leaves us in the situation of supporting older software for the long
term, and older software requires more resources to support.

>  2. Ship both Linux 2.6.12 and 2.6.new
> 
>     I suggest we ship two kernels with dapper: A well tested and stabilised
>     2.6.12 for servers and a nicely up-to-date 2.6.new (probably 2.6.14) for
>     desktops. This does mean extra work, but while we're tracking the fresh
>     branch, we can fold fixes back into the 2.6.12 branch. Potential gotchas
>     include: incompatible inotify and udev changes (kernel/userland combos
>     elsewhere, too), desireable new stuff for servers such as the upcoming
>     SCSI changes not being backportable to our stable branch (thanks to
>     James Troup and Daniel Silverstone for pointing these out).

We need to choose one kernel to use by default, to go on the CD, so to a
certain extent we wouldn't be able to take full advantage of dual kernels.
We would also double our patch management workload, and would need to make
some tough calls as to which of our patches should be backported to the
older kernel.  I think that we could more adequately utilize our development
resources and achieve the same goals by focusing on a single kernel tree.

We do already offer them a choice if they need it.  Breezy is still
supported for 18 months, and users who have problems with a newer kernel can
stay behind until their issues are resolved in Dapper.  Likewise, if Dapper
doesn't have their bug fix, they have the option of jumping ahead to
Dapper+N, N=1..10 at any time.

-- 
 - mdz