hey, I've had discussions with a number of folks at DebConf this week about how we might add new hardware support to a stable release after its first release. The most well-received suggestion has been to add an additional updated kernel in a stable point release - perhaps near the middle of the release's scheduled lifespan, or when some milestone in upstream kernel development occurs. Members of the stable release, stable security and d-i teams all appeared to be quite open to this discussion.
For example, if we shipped etch with 2.6.15 today, we could later add *optional* 2.6.20 package backports into official stable. d-i would need to be updated with this kernel of course, and we wouldn't want to change the default behavior for current stable users by making the new kernel the default. Instead, it could be a new boot-time selection (like 2.6 currently is for sarge/i386). Of course, this means maintaining security support for an additional kernel; however, doing so in etch would still be an improvement over sarge & woody. Instead of shipping both a recent and an old kernel on day 0, we would ship a recent kernel on day 0 and an even more recent kernel a number of months later. If we want to prepare for this possibility, the one issue that the d-i folks pointed out is that we'd probably want to refactor our meta packages such that we could have both metapackages for the latest 2.6.N and additional packages for the latest 2.6.N+, so users can track whichever they prefer. One suggestion was to use linux-image-etch-foo for tracking 2.6.N and something like linux-image-etch+-foo for tracking the 2.6.N+ update. Note that this is in the context of etch instead of sarge because there are a number of transitions that make such an update quite difficult in sarge (devfs removal, udev, initramfs transition, linux-2.6 transition, etc). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
