Message-ID: <alpine.LFD.0.999.0707281313570.3442@woody.linux-foundation.org>
Date:	Sat, 28 Jul 2007 13:31:04 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	jos poortvliet <jos@...nkamer.nl>
cc:	ck@....kolivas.org, Michael Chang <thenewme91@...il.com>,
	Kasper Sandberg <lkml@...anurb.dk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: Linus 2.6.23-rc1



On Sat, 28 Jul 2007, jos poortvliet wrote:
>
> Your point here seems to be: this is how it went, and it was right. Ok, got 
> that.

But I wanted to bring out more than what you make sound like "that's what 
happened, deal with it". I tried to explain _why_ the choices that were 
made were in fact made.

And it's a (I think) important thing for people to be aware of. The fact 
is, "personality" and "work with the other developers" is a big issue.

You cannot just go off and do your own thing in your private world, and 
then expect it to be accepted without any discussion or other people 
showing up and doing alternate things. That's _especially_ true in an area 
that has a respected and working maintainer.

>	 Yet, Con walked away (and not just over SD). Seeing Con go, I wonder 
> how many did leave without this splash.

We've had people go with a splash before. Quite frankly, the current 
scheduler situation looks very much like the CML2 situation. Anybody 
remember that? The developer there also got rejected, the improvement was 
made differently (and much more in line with existing practices and 
maintainership), and life went on. Eric Raymond, however, left with a 
splash.

It's not common, but it's not unheard of. Anybody who thinks that 
developers don't have huge egos probably haven't ever met a software 
engineer. And I suspect kernel people have bigger egos than most. No 
wonder there are clashes every once in a while - it's a wonder there 
aren't _more_ of them.

> How and why? And is it due to a deeper problem?

Well, one part of it is that the way to make changes in the kernel 
community is to do them incrementally.

Small and incremental improvements are much easier to merge. If you go off 
and rewrite a subsystem, you shouldn't expect it to get merged, at least 
not unless it can live side-by-side with the old one (the new firewire 
stack is an example of that, and most filesystems are this way too). And 
the closer to some central part you get, the harder that gets.

So the *bulk* of the kernel stuff can be handled either incrementally, or 
side-by-side, and as a result, you actually seldom see issues like this. 
The kernel is extremely modular, and a large reason for that is exactly to 
avoid couplings.

Some (very few) things cannot be done incrementally. That's why I bring 
up CML2 as a fairly good example of this having happened before. Some 
things require flag-days. But you should pretty much *assume* that if 
there is a flag-day, and if there is a maintainer, the maintainer has to 
be involved.

Does "maintainership" give infinite powers? No. I'll take patches that 
bypass maintainers, but there needs to be some reason for them (ie in some 
sense the maintainer needs to have done a bad job, or the patch just needs 
to be trivial enough - or it cuts across maintainership areas - that it's 
not even _worth_ going through all maintainers).

So maintainers aren't "everything". But they are important. You can't just 
ignore them and go do your own thing, and then expect it to be merged.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists