Eh.... I will just throw a small bit in here. Linus isn't the
supervisor for David. And since David is doing the work for *FREE*
there remain quite the question how are you going to wight
the convenience of one against the other?
> 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.
Yes and frequently those are the users who are still using obsoleted
hardware which is only making a 5%% of the whole market for this class
of
devices becouse the users who couldn't get they hardware working with
the badly designed previous version of the drivers are FAR LESS LIKELY
to notice that something actually STARTED TO WORK FINE! And just take
into account that people are by far more likely to demand something
instead of giving you kudos for something.
> 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?
No the only thing which is sucking here is the simple fact that if
Donald is going to do always only the incremental approach with
the assumption that every code line he produces has to go through
Linus:
1. he will spend more time arguing about every single thing every time
the whole wave of users starts to complain.
2. As a separate second point or in the implication of the former, he
will never be able to make fundamental changes to the overall driver
design.
3. Everybody will think that Linus did the only work.
The thing which is sucking here is the fact that there isn't
any real delegation of the responsibilites. If David where able to
work relatively *NONSUPERVISED*, by using the server at transmeta just
as his data repository all the problems you are describing wouldn't
exists.
And with time all the users would know that they should bother
Donald with ether stuff instead of Linus - who donsn't know better then
him in this area. (Do you remember Mark Lord for example????!!!!)
It's just a matter of fact that Linus should lose his gripes on at least
this particular part of the kernel.
The incremental approach, which you are proclaiming as the
only feasible way of managing collaboartion, which is allways trying to
keep every intermediate version of the kernel quite stable at least
with repect to the drivers is basically starting to hurt the
overall developement process. See for example why there still isn't
no true overall support for dynamic device detection. Why there isn't
still any support for, yes lets take a trivial example of a small change
which is going to suddenly break many things: long kdev_t :-).
Or have a look at the whole interface mess in the following areas:
1. modularization interface.
2. /proc (or better /trash...)
3. raw devices (the whole presetup thing is just unnccessary kludgy
added complexity in comparision to the original UNIX design.)
4. GPM / console
...
Basically becouse those are all things which can't be resolved
incrementally. (Try to clean up procps the
incremental way without breaking anybody's wired setup if you like.)
Due to the fact that the developement of user-land is very separated
from the kernel there is a similiar kind of deadlock here, since
one can't redesign interfaces incrementally without taking both sides
simultaneously into account.
If it where for example clear that all the net-tools, until-linux
isapnputils and so on, all could be worked on simultaneously,
it would be really really much easier to resolve many kinds of problems,
which in my oppinion are slowly starting to accumulate.
Note: I'm not talking about cat, tar and friedns here. I really
mean those utlities which are basic ground parts of the OS hardware
suppor but which just happen to don't run on Ring 0 level.
But as a reward for the incremental-only approach to software
developement
we still have support for oh... let me go to the extreme:
QIC-20 tapes and XT MFM hard drives and non IDE/SCSI proprietary
CD-ROM interfaces, Amiga hardware,
which is essentially preventing everybody from
doing serious changes to the lower driver interfaces. For the
user it's basically only a curiousity. (And therefore
even more kludges start to appear like devfs for example...)
That's great! But the only thing it's good for is
waste of badwidth for the always increasing kernel tar-ball.
(If somebody incidentially runs XT discs he should stick to SLD linux
for example and basta.)
--Marcin
-
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/