Messages in this thread |  | | | Date | Wed, 20 Oct 1999 12:41:19 -0700 | | From | "David S. Miller" <> | | Subject | Re: PATCH 2.3.23 pre 2 compile fixes |
| |
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/
|  |