Re: PATCH 2.3.23 pre 2 compile fixes

David S. Miller (davem@redhat.com)
Wed, 20 Oct 1999 12:41:19 -0700


Date: Wed, 20 Oct 1999 15:21:38 -0400 (EDT)
From: Donald Becker <becker@cesdis1.gsfc.nasa.gov>

I've done it in a way that minimizes the your workload, and makes
the updates and new drivers immediately available to those with
stable kernels.

As Linus has described, and what you seem to have problems
understanding, is that _this_ very technique _maximizes_ Linus's
workload.

This seems to be the source of your confusion. Batching up sets of
fixes over a long (ie. not timely) period of time, and then sending
them all at once for integration is about the worst thing you can do.

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.

This change is fine and nobody complains of breakage.
You run through this process about 3 or 4 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.

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.

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
are not backed out and not lost. Whereas in situation #2 he has to
back the whole thing out, and all the work is gone until things are
remedied, and you'll probably repeat the cycle as other bugs are found
whilst you keep resubmitting this huge patch, and eventually Linus
(like right now) will get disgusted with the whole mess.

Now can you see why your "external from the main tree for months"
development process sucks and causes grief for everyone?

Later,
David S. Miller
davem@redhat.com

-
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/