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.
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 ...
-- James Bottomley
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
-- 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:
- 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
-- Andrew Morton
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
-- 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
to post comments)