On Fri, Jan 18, 2002 at 09:28:44PM +0200, Shlomi Fish wrote:
>
> In that case, maybe we should make sure that the code is:
> A. on CVS.
> B. Every sub-system maintainer can commit patches to his own subsystem
> without asking Linus.
>
> Making everything pass through one person is very unscalable.
Development of OS code is unscalable by its nature. The pieces can
be highly and dynamically interdependent, so they need to be
contrasted and syncrhonized. Linux has a bottom-up development
model -- people keep on suggesting patches, some of them good, some
of them bad, and many of them conflicting with one another. Those
patches float through other subsystem maintainers or maintainers of
independent trees if they're any good, and the final station is
Linus's tree. This is very different from a top-bottom model where
the top guy pronounces what needs to be done, and the maintainers
break up the task and make it more detailed, until it gets
implemented and committed into the CVS tree. In the top-down model
the general direction comes from the head of the project, and only
later do we see code implementation. In the bottom-up model, the
project maintainer hardly ever has to think about new ideas because
they keep on being suggested from the bottom, but (at least in
Linux) these ideas would not even be considered until there is
actual code to discuss, usually also benchmarks to compare, and at
times even positive reviews from a large user community. In the
bottom-up approach, the main task of the project maintainer is to
select patches for inclusion based on his understanding of the code
and the needs.
Thus, eliminating Linus's role as the patch selector still will
not solve the essential problems. Linux is not like Debian, which has
thousands of packages and where, on the most part, the only
communication needed between developers revolves around
standardization. In Linux, every part affects everything else, and
the solutions are very rarely obvious. The division of responsibility
is often much fuzzier. For instance, even though the kernel now
contains the VM developed by Andrea Arcangeli, some of the
improvements for it ("the rmap patch") that have seen best reviews so
far are by Rik van Riel, no less. Alan Cox has accepted it into his
tree and if they continue to receive good reviews I would not be
surprised if they show up in Marcelo's and Linus's as well. That is,
there is no one "VM maintainer" in Linux, but there are several VM
hackers and interested people, who debate and argue and offer
conflicting patches, with Linus being the final arbitrer.
Now, there are other subsystems that are more independently run. The
VM and the scheduler are the ones that are the most central to the OS
and the ones for which it makes less sense to have a single
maintainer, and indeed there isn't one. Drivers are on the opposite
side -- they are so numerous and the interfaces to them are so
relatively stable that who is their maintainer is never in question.
Indeed, Linus usually accepts patches from driver maintainers
immediately, and was even criticized for the inconsistency and lack
of quality of driver code compared with rest of the kernel (mostly by
Alan Cox). Filesystems are somewhere in the middle.
> Like I said the maintainer of a subsystem will have commit access to his
> subsystem. It makes no sense that the maintainer of, say, the ext3
> filesystem will have to pass his patch to Torvalds first. He can simply
> commit it into his tree in the CVS (or BitKeeper, or Subversion or
> whatever)
..Or just have Linus automatically accept patches from maintainers.
You can separate the social organization from the technical means
used to implement them, because they are completely unrelated. The
"Linux patch acceptance path" is not slow and unreliable because
Linus's mailer sucks, but because Linus reviews each patch and often
rejects or ignores patches that he doesn't like. Don't blame the
mail, blame Linus's maintainership.
And by the way, filesystems -- especially ones that introduce new
concepts, such as journalling -- can often have global ramification,
because they define new interfaces and new methods to do things that
will be referred to and become difficult to get rid of. Another thing
is that it is desireable (as Alan Cox often says) to avoid putting in
two changes that are somehow in contact at the same time, because it
makes debugging difficult. For instance, if you put in a filesystem
update and an IDE update at the same time, and then someone reports
a filesystem corruption bug under rare circumenstances, good luck
trying to hunt it down. If you put in those changes one at a time,
at least you can be sure where the bug is. For all those reasons
Linus might want to reject or postpone an ext3 patch.
> > - How to resolve disagreements between different maintainers
>
> You probably mean on something that affects the whole kernel. I suppose
> Linus should have the ultimate decision. However, I believe he should
> designate other people who could make such decisions in case he has not
> voiced it for a long time.
Either he makes the final decisions, or he doesn't and someone else
does. I don't understand what you mean by what you suggest and what
it would achieve.
> I believe Linus is making the same mistake Moses did (if anybody remembers
> that story from the Bible). He thought every Israelite should address him
> on every little matter. But then Jethero suggested him to have the Sarey
> Alaphim, Sarey Meoth, etc. system, where problems were handled at a lower
> level.
It's done this way, sure. But a balance is important. If Linux is
too centralized, we risk slow development and developer discontent.
But if it is too distributed, we risk unclear and inconsistent code,
unclear and inconsistent behaviour, bad, untested or unnecessarily
controvertial changes, subtle bugs on the interfaces between
components, and therefore increasing difficulty in extending the
system. Finding the right balance is tricky.
> > - How to decide the general direction of the kernel
>
> I don't have a problem with Linus deciding it. If anybody has problem with
> what Linus decided, he should fork and create an alternative kernel.
Linus says that "the real world is dominated by implementation
details" (I don't remember who he was quoting), so the correlary
is that Linux's general direction is dominated by its source code.
> Perhaps Linus should write a manifesto of the Linux kernel. Tell about its
> philosophy, etc. In any case, everything cannot pass through one person as
> is the situation now.
This changes constantly. If you could write such a manifesto that
will remain unchanged for more than a few months then there would
really /not/ be a need for Linus.
> > Once such an alternative project management is sorted out and
> > working, then whetehr it actually uses CVS for its sourse code
> > management is only of secondary importance.
> >
>
> I disagree. A CVS can help the different maintainers work on the same code
> base, while not interfering with the other ones' work.
No. Good interfaces, good understanding between the developers and a
clear division of responsibility do. If you don't have that, no
source control system will help.
> As you see everything can be resolved with a little amount of reasoning.
> Do you think that the President of IBM or Intel or (god-forbid*)
> Microsoft, should be involved in any of the decision each one of its
> engineers make? I don't think so, and neither should Linux. It has reached
> the state where it's impossible to pipe everything through one person.
> (and this time - the UNIX pipes analogy is perfect)
Linux's mode of development is very, very different from Microsoft's
or IBM.
If I am following your line of reasoning correctly: Linus's role is
to apply patches from maintainers to the main tree, and he's doing a
worse job than CVS. CVS is provably able to apply 100% of the patches
from maintainers, and therefore if Linus is known to drop patches he
is doing suboptimal job.
I believe Linus's original analogy was "CVS with taste", that is, he
will only accept good patches and drop the bad ones. If Linus accepts
a bad patch it is just as bad as not accepting a good patch. Anyone
can fork the code, and many people did, and do, and distributions can
choose other forks and apply other patches. The power that Linus
holds is to be able to say "but /this/ is the set of patches that /I/
believe in and think they should be the basis for future growth". If
he doesn't approve of the patches himself, he can't do that. (And if
this role is not needed, then we wouldn't be having this discussion.)
You can say he's doing a lousy job, though.
> I guess I'll rename the mutiny to the "Great Linux
> Kernel Meta-Reorganization Mutiny", of which CVS/BitKeeper/SBV would be
> just one of its proposals.
I don't think you are completely clear on what this meta-organization
will look like. You will have a hard time getting any of the kernel
hackers to even listen before you can show why it will work better.
No doubt Linus's handling of the 2.4 series was problematic, he
admitted so himself, but I can't see how what you suggest could solve
the specific problems that 2.4 had.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
