Release management thoughts for Dapper Drake

Jeff Waugh jeff.waugh at ubuntu.com
Fri Oct 14 07:18:11 CDT 2005


Hi all,

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)


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


Both suggestions will increase the testing exposure of the stable components
as they'll see active use in both breezy *and* dapper. I think it would suck
to ship a long-term supported release with only the testing it will receive
during its six-month development cycle - that's not going to be enough.

Thanks,

- Jeff

-- 
linux.conf.au 2006: Dunedin, New Zealand               http://linux.conf.au/
 
    Ye shall be cursed to fall in love so easily, and yet be so cold of
                       heart as never to express it.



More information about the ubuntu-devel mailing list