[lkml]   [1999]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [W:0.090 / U:0.264 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site