![]() | |||||||||||||
Messages in this thread |
Adrian Bunk wrote: > 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, Yes, this is an unlikely scenario. > and OTOH the value of the added support is more realistic. But then I think people don't really expect additional hardware support from a stable kernel series. > 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. If there was more manpower, driver updates could be maintained as extra patchkits separately to the kernel. I know that some people would like to have exactly this: A minimally updated base plus a choice of specific driver updates as add-ons. In fact that's what I do with the IEEE 1394 drivers --- although not primarily to support this kind of user base but rather to make it easier to get bugfixes tested by bug reporters. However I can only afford to do this by an all-or-nothing approach: I put almost _all_ driver changes into these patchkits. That means full risk of regressions but also complete feature updates and minimal divergence from mainline. This was trivial to do so far. -- Stefan Richter -=====-=-==- =--= ==--- http://arcgraph.de/sr/ - 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/ | ||||||||||||
| Last update: 2006-09-24 21:55 [from the cache] ©2003-2008 | |||||||||||||