RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Arjan van de Ven <arjan@infradead.org>]

On Tue, 2007-07-31 at 23:16 -0700, Hua Zhong wrote:
> > Did Ingo have the obligation to improve Con's work? Definitely not.
> > Did Con have a right to get Ingo's improvements or
> > suggestions? Definitely not.
> 
> Yes, and that's where the inequality is.
> 
> Unless the maintainer does a really bad job or pisses off Linus,
> anyone who wants to merge his code into mainline pretty much
> has to get the blessing of the maintainer. On the other hand,
> as you just said, the maintainer has no such obligation.


I think a lot of people are missing some key things here:

It does not matter who's code gets merged.

The CFS-SD competition was a GOOD THING. Both sides were in heavy, fast
improvement mode, and competed on all fronts and borrowed heavily from
eachother in terms of ideas that worked, and innovated to stay ahead.
The end result is that both were good schedulers, and Linux won by
getting the fruit of this competition. Think of it as a mini-evolution
of scheduler ideas compressed into a short time period.

Now compare this to a single patch without competition/the need to
survive in the habitat, say the first SD or the first CFS patch....
whatever your poison is. If there had been no competition element, we
would have ended up with either one of those, and it would have been not
nearly as good as they both ended up as in the end.

Who wrote the code is not relevant in the large picture, the fact that
the problem at hand (2.6 scheduler behavior) got solved is. 

I wish people would focus less on who wrote the actual code that got
merged in the end, and more on the problem that got solved.... People
who care about the desktop should be happy that the scheduler improved a
lot due to the competition where the two new schedulers were hair-close
in most aspects. Again.. think about the problem being solved. Not who
wrote the code or which of the competitive patches got merged in the
end.

Let me repeat the key message:

It does not matter who's code gets merged.
It does not matter who's code gets merged.
It does not matter who's code gets merged.
It does not matter who's code gets merged.

What matters is that the problem gets solved and that the Linux kernel
innovates forward.


I've had several cases myself where I spent quite some time solving a
problem, just to get some random remark from someone smart on lkml
saying "if you had done <this simple thing> you would have had <this
simple and superior solution>". Was I pissed off that my patch didn't
get merged but that this better approach got picked? NO! The problem
that I needed to solve got solved in a really good way. Mission
accomplished.

(and merging the code that is cleaning up/smallest is a reasonable one
to pick for someone like Linus, likewise for the "which is likely to be
maintained best" arguments)


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

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