Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Those who have been watching the linux-kernel list know that the 2.6.26
merge window has been a little rougher than some of those which came
before. That has led to some fairly strong discussion over how changes
find their way into the mainline. Here's a few selections.
I'm not saying the patch is wrong ... or that just because it broke
voyager it shouldn't be done. What I'm saying is that it shouldn't have
been put into the x86 tree without mailing list review.
-- James Bottomley
Running a git tree isn't a private fiefdom, it's a public trust; to keep the trust of other developers, you have to run the tree in a transparent fashion ... and making the mailing list the only input to it is one way of ensuring this. It also helps with review that we're all so worried about so little being done ...
But, we'd not mind at all posting 1000 x86.git patches to lkml (or
another list) every 3 months (or more frequently), if people request
that.
-- Ingo Molnar
You can post whatever patches you like a million times to lkml.
That's not the problem.
It's that the patches don't get reviewed, posting them more or to a
different place doesn't help that.
-- David Miller
Sorting x86 arch code is inevitably going to break a few eggs, but I
suspect the time cost has been more in Dave v Ingo (12 rounds, two falls,
two submissions or a knockout) than actually sorting out the fallout of a
couple of problem cases.
-- Alan Cox
So here's how we're going to fix David's problem:
-- Andrew Morton
- Everyone gets their stuff into linux-next. - Lots of people _test_ linux-next. Just once a week. Those two steps will improve the merge-window chaos a lot. Things will get better.
IMO, the merge window is way too short for actually testing anything. I rebuild
the kernel once or even twice a day and there's no way I can really test it.
I can only check if it breaks right away. And if it does, there's no time to
find out what broke it before the next few hundreds of commits land on top of
that.
-- Rafael Wysocki
And yes, there is a solution: don't develop so much. Don't allow thousands
of developers to be involved. Do a small core group, and make development
so hard or inconvenient that you only have a few tens of people who write
code, and vet them and force them to jump through hoops when adding new
features (or fixing old ones, for that matter).
-- Linus Torvalds(Log in to post comments)
Quotes of the week Posted May 1, 2008 10:53 UTC (Thu) by dale77 (guest, #1490) [Link] So on the grand continuum between thousands of developers and the small core group of tens, where does linux stand today, practically? From the outside, I see evidence for both being true, in their spheres... Thoughts?
Quotes of the week Posted May 1, 2008 11:55 UTC (Thu) by man_ls (subscriber, #15091) [Link] The kernel is firmly in the thousand+ developers. The weird thing is not that code is occasionally broken, but that it ever works at all. It must be a unique case in the world in this respect.
thousands of developers, high flux development Posted May 1, 2008 12:42 UTC (Thu) by mingo (subscriber, #31122) [Link] If we were just mindlessly developing away and added features no end it would indeed quickly result in chaos. In reality, while there is about 1 million lines of code changed in every Linux release - added every 3 months, by thousands of kernel developers - a significant portion of that activity is not new features but hardens the code for future changes. We do that on a code base that is kept "clean" very aggressively. A clean code base is the stepping stone to the fluid integration of a new feature. another effect is that about half of the incoming flux is 'pending', and there's a pretty aggressive selection process over that pending set of changes. There are changes that get rolled forward from release to release, when they are still found to cause problems. a third effect is the eat-your-own-dog-food policy. I run my own development branch on most of my machines, so i'm directly exposed to its quality. That's a rather good reality check in practice. (although it is by no means a complete and accurate impression) And i _can_ run my own development branch on most of my machines because the kernel is rolling updated and is supposed to stay compatible all the way - and Linux distributions have adopted to that. But ... i'd be the first one to admit that it is all looks very crazy and it's a miracle that it works. But it really does - and from a similar chaos did intelligent life emerge on our planet. (or at least it is speculated to have emerged ;)
contributor statistics Posted May 1, 2008 12:36 UTC (Thu) by Klavs (subscriber, #10563) [Link] Perhaps the contributor statistics can help you answer that? http://lwn.net/Articles/264440/
|
|||||||||||||