> Let me give you two situations to show you why this is true:
> situation 1) You fix a bug today, you send Linus just that small
> change to one specific driver, to fix that bug.
That's almost never the case.
For drivers that support many cards I usually have ten different
modifications outstanding, each one to attempt to fix a specific reported
problem. Most changes either don't fix the problem, or are known to cause
other problems. It's often a week or two before a test versions is
reported on, so many times there is no way to serialize the changes.
I usually have a extensively tested stable version, with "try this fix on
v0.91" branches, a tested semi-stable version, also with branches ("v0.91u
crashes? See fi this hacked v0.91g-ppc version works"), and an barely-test
has-every-enhancement version.
> This change is fine and nobody complains of breakage.
> You run through this process about 3 or 4 times.
50 times.
> On the 5th change, again small and specific and
> incremental, Linus and others note that people begin to
> complain of problems. These people also proclaim that
> before this 5th change went in things were perfectly fine
> for them.
I always discount isolated reports. How many times have you heard "the
older kernels didn't sig-11 with gcc". I get "your latest driver version
stopped working" (when no version could have worked with their bad routes or
mis-paired cross-over cable).
> situation 2) You spend 4 months, and fix dozens of bugs, and also
> have reworked major sections of code in a driver to
> support new cards, or do whatever. You send one big
> fat patch to Linus after this 4 month period, many
> users complain that the driver suddenly stops working
> for them in a big way.
During that time I annouce the updates to the driver mailing list, make many
test versions available, and test the driver myself. I have well over 100
cards, and a handfull of machines.
> In situation #1 Linus needs only to back out patch #5 or seek a remedy
> from you for that specific change, the fixes in patches 1 through 4
And the driver code would never be cleaned up, or reworked because a new
chip changed things.
> Now can you see why your "external from the main tree for months"
> development process sucks and causes grief for everyone?
The "only add patches to the latest kernel" approach means that people have
to update to a usually-broken kernel to get a undated board revision to t
Donald Becker
Scyld Computing Corporation, and
USRA-CESDIS, becker@cesdis.gsfc.nasa.gov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/