Re: Linux 2.6.16.30-pre1

On Sun, Sep 24, 2006 at 09:46:17PM +0200, Stefan Richter wrote:
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.

If there was more manpower, the same principle as I adopted for the
2.4-hotfix series would be applicable :

- maintain multiple older versions in parallel
- only apply critical fixes.

=> That way, people choose the version they will work with based on a
feature set, and they benefit from fixes only. But this is an ideal
world, and as Greg told us (and demonstrated), 2.6 is moving too fast
to permit the maintenance of multiple branches in parallel. We won't
clone Adrian for every new 2.6 which comes out :-)

However, I noticed (in 2.4) that raising the patch acceptance threshold
for a hotfix reduces the conflicts between versions and reduces the
amount of work needed to maintain multiple versions in parallel. I have
only 192 patches to cover all identified fixes between 2.4.28 and 2.4.33
and only one or two of them did require manual merging for old versions.
Anyway, this is still boring work.

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/

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • cvs-src summary for 14/03/04
    ... Tom Rhodes committed support for using `Intel's icc C compiler`_ ... Important bug fixes ... This commit closes `PR 62536`_, ...
    (freebsd-current)
  • Re: XP license to 2nd computer legal?
    ... WinXP is the first MS product to use this activation method, ... Without MS support, ... As of now, you have to install, & ... fixes as it is. ...
    (alt.comp.hardware.pc-homebuilt)
  • Re: Rules to setup project version numbers?
    ... Increments when each build is created. ... be accessible by users so they can accurately report it to support. ... Minor version is usually a marketing thing (meaning developers do ... announce 1.2 with all accumulated fixes. ...
    (borland.public.delphi.non-technical)
  • [BK PATCHES] 2.6.x experimental net driver updates
    ... e100/e1000 fixes ... via-rhine netpoll support ... o [netdrvr bonding] Add support for slaves that use ethtool_ops ... o [netdrvr bonding] Releasing the original active slave causes mac address duplication ...
    (Linux-Kernel)
  • Re: Linux 2.6.16.30-pre1
    ... I avoided to add support for new hardware. ... enough, and to separate security fixes and such fixes in distinct releases, ... any big updates in this area). ...
    (Linux-Kernel)