Messages in this thread | | | Date | Sun, 24 Sep 2006 20:16:41 +0200 | From | Adrian Bunk <> | Subject | Re: Linux 2.6.16.30-pre1 |
| |
On Sun, Sep 24, 2006 at 01:53:15AM +0200, Willy Tarreau wrote: > On Sun, Sep 24, 2006 at 01:21:50AM +0200, Adrian Bunk wrote: > > On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote: > > > Hi Greg, Hi Adrian, > > > > > > On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote: > > > > > > > If you want to accept new drivers and backports like this, I think you > > > > will find it very hard to determine what to say yes or no to in the > > > > future. It's the main problem that everyone who has tried to maintain a > > > > stable tree has run into, that is why we set up the -stable rules to be > > > > what they are for that very reason. > > > > > > When I started the 2.4-hotfix tree nearly two years ago, I wanted to > > > avoid merging drivers changes as much as possible. And particularly, > > > I avoided to add support for new hardware. The reason is very simple. > > > I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y > > > does too so that they can blindly upgrade. > > > > Bugfixes causing regressions are much more likely than new hardware > > support adding regressions. > > > > > And if, for any reason, > > > people suspect that 2.4.X.Y might have brought a bug, then reverting > > > to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove > > > previous support for any hardware. > > > > Either you want to use the newly supported hardware or you don't want to > > use it. > > > > In any case, I don't see your point. > > The problem is when some hardware suddenly become detected and assigned > in the middle of a stable release. Do not forget that people need stable > releases to be able to blindly update and get their security vulnerabilities > fixed. Sometimes, unlocking 2 SATA ports on the mobo by adding a PCI ID or > adding the PCI ID of some new ethernet cards that were not supported may > lead to such fun things (eth0 becoming eth2, sda becoming sdc, etc...). > This causes real trouble to admins, particularly those doing remote > updates. At least, I think that if you manage to inform people clearly > enough, and to separate security fixes and such fixes in distinct releases, > it might work in most situations. But this is a dangerous game anyway.
It seems we do not always agree. ;-)
I did consider gcc 4 support in kernel 2.4 more dangerous and you do consider this more dangerous than I do.
I can always be proved wrong by getting reports from people that I broke their setups. If you know someone whose setup I broke, please tell him to inform me about this fact.
That zero feedback is good feedback is my experience since the times when I offered packages to run kernel 2.4 on Debian 2.2, and later packages to run kernel 2.6 on Debian 3.0 - I got almost zero feedback except for the one time when an update removed /etc/services ...
> > > The problem with new hardware > > > support is that it can break sensible setups : > > > > > > - adding a new network card support will cause existing cards to be > > > renumberred (it happened to me on several production systems when > > > switching from 2.2 to 2.4) > > > > > > - adding support for a new IDE controller can cause hda to become > > > hdc, or worse, hda to become sda (problems encountered when adding > > > libata support) > > > > I don't consider merging any patches that could cause the sda problem. > > > > People not using the onboard IDE controller but a different controller, > > but OTOH having the driver for their onboard controller enabled in their > > kernel really sounds like a strange case. > > No, this one is common, it's the reverse which is uncommon. Think about it. > You buy a mobo, you discover that the onboard SATA is not supported, you add > a new controller but do not disable the old one in case you have time to > perform more tests. > > Anyway, the case above was even not that. It was simply that if the shiny > new sata_piix driver detected the sata controller, it would then steal the > resources first, preventing ata_piix from registering.
I know that ATA is an area that requires extra care (and I don't plan any big updates in this area).
But having: - two saa7134 cards in your computer and - one of them formerly not supported and - depending on one of them being the first one is a case you can theoretically construct, but then there's the point that this is highly unlikely, and OTOH the value of the added support is more realistic.
If I was as extremely regarding regressions as you describe regarding hardware updates, I would also have to reject any bugfixes that are not security fixes since they might cause regressions.
I do know that the only value of the 2.6.16 tree lies in a lack of regressions and act accordingly, but I'm trying to do this in a pragmatic way.
> Cheers, > Willy
cu Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |