On Wed, 23 Mar 2005 19:27:20 +0000, Matthew Wilcox wrote: > On Wed, Mar 23, 2005 at 04:09:42PM +0100, Frank Lichtenheld wrote: >> How big is the chance that we will have another ABI change during >> sarge's lifetime (100%?). So it can't hurd to figure out the problems >> with that now independently of our decision in this matter... > > Absolutely. It's bound to happen again. We also need to figure out > how to do driver updates during sarge's lifetime. I suspect virtually > everybody has had the experience of trying to install woody on a new PC. > Some of the problems I remember: > > - new PCI IDs for the eepro100 driver > - i830 chipset not supported (also needed new X) >
Unfortunately, a driver update is rarely the case of simply adding new PCI IDs. They usually end up updating some random register poking, which is done because of some errata that's NDA'd or sitting on some nameless webserver in .tw somewhere. I have come to fear those sorts of updates, because a) I typically don't have the hardware available to me, and b) people don't report bugs, so if the update ends up being a regression for some bit of hardware, the kernel team doesn't find out about it for a while, and c) when we do find out about a regression, getting people to test new drivers is a long and drawn out process (w/ lots of folks using the hardware in production, so they're unable to test). OTOH, I have hardware that's already not supported by sarge (VIA video chipset that's only supported by xorg). As much as the security team is loathe to support multiple kernels, it does seem like having multiple kernels in d-i is the safest way to support this sort of thing. We get this for free in sarge, by having 2.4 and 2.6 kernels. In the future, it might be worth having multiple 2.6 kernels, or decoupling drivers from core kernel stuff (core kernel stuff is generally fairly easy to see regressions in, so there's no need to have multiple version of that). > Does d-i have an option to insert a driver disc (floppy or cdrom) or > ability to grab a new module package from the net (suboptimal as it may > be the network driver that's missing)? > This will be something that's desirable for kernel-source-nonfree, in the future, as well. > Either that, or we need to commit to a 6-month release goal for etch and > future releases. Which wouldn't suck, we used to do it... > > Buzz (1.1): June 1996 > Rex (1.2): December 1996 (6 months) > Bo (1.3): June 1997 (6 > months) > Hamm (2.0): July 1998 (13 months) > Slink (2.1): March 1999 (9 months) > Potato (2.2): August 2000 (17 months) > Woody (3.0): July 2002 (23 > months) > Sarge (3.1): ? (32 months and counting) Of course, 6-month release cycles would be the ideal situation. It's much easier for people to try different versions of distributions for hardware compatibility, versus reading documentation on d-i, passing in various kernel and boot args, loading different versions of drivers, etc. This isn't an option for most people currently, since woody is so stale. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
