Messages in this thread | | | Date | Wed, 20 Oct 1999 17:07:26 -0400 (EDT) | From | Donald Becker <> | Subject | Re: PATCH 2.3.23 pre 2 compile fixes |
| |
On Wed, 20 Oct 1999, David S. Miller wrote:
> 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/
| |