Release management thoughts for Dapper Drake
[Posted October 17, 2005 by corbet]
| From: |
| Jeff Waugh <jeff.waugh-AT-ubuntu.com> |
| To: |
| Ubuntu Developers <ubuntu-devel-AT-lists.ubuntu.com> |
| Subject: |
| Release management thoughts for Dapper Drake |
| Date: |
| Fri, 14 Oct 2005 13:18:11 +0100 |
| Archive-link: |
| Article,
Thread
|
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.
(
Log in to post comments)