Release management thoughts for Dapper Drake

[Scott James Remnant]

On Fri, 2005-10-14 at 13:18 +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. :-)
> 
>  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. In practice, this means halting our autosync
>     with Debian sid, and only accepting uploads and syncs for approved fixes
>     and feature goals - except for universe, which we should continue to
>     sync, otherwise the MOTUs and our archive/buildd admins will drive each
>     other crazy.
>     
>     What's not covered by exceptions are boring things we expect to be rock
>     solid, such as core system components and server software (apache,
>     dovecot, postfix, squid, etc). Some of the more obvious feature goal
>     exceptions I imagine we'll accept at UbuntuBelowZero include:
> 
>     * GNOME 2.14, KDE
>     * Firefox 1.5
>     * Xorg 7
>     * OpenOffice.org 2
>     * Linux 2.6.new (probably 2.6.14)
> 
Which pretty much defines dapper main ... so exactly what do you want to
freeze again?!  I think if we do want to do this "stable upstreams"
release, the first things we should ditch are the above set and instead
release with a known-good GNOME 2.12, Xorg 6.8, etc.

And I still think it's a bad idea; we've built up our reputation and
user-base on the idea of having 6-monthly releases of the latest
software -- and to suddenly not do that for a release seems like a
mistake to me.

>  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).
> 
Given the kernel is our primary source of hardware compatibility and
drivers, having two kernels seems like just making like difficult for
our users.  "Do you want the kernel behind door A, or door B?"

Scott
-- 
Scott James Remnant
scott at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20051015/919de09d/attachment.pgp