Release management thoughts for Dapper Drake

[Martin Pitt]

Hi!

Jeff Waugh [2005-10-14 13:18 +0100]:
>     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

This is actually a very good example. Our current udev currently
provides obsolete features like support for /etc/hotplug/ and
/etc/hotplug.d scripts, our current libsane and libgphoto still rely
on USB usermaps and thus are never really up to date for current
hardware. Also, this mechanism is pretty fragile (as shown in various
bug reports I talked about with Scott).

2.6.14 and the new udev will not have any support for these scripts
any more; instead, packages should move from accessing devices in
/proc/ and instead use properly udev-configured devices in /dev, which
avoids these hotplug scripts, user maps, etc, and is likely to be much
more robust than the current solution.

Given that in three years our current hotplug maps will be hopelessly
out of date, and a lot of cleanup happens in Debian right now, we
should certainly follow this approach instead of wasting resources for
hacking on the current obsolete solution IMHO.

Jeff, what do you think? Would this be a valid exception in your
release plan, although udev and hotplug are not in the list of
exceptions?

Martin

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20051017/93cd985a/attachment.pgp