New Kernel 2.4 Development Branch (-mjc)
Ivo writes: "kerneltrap is reporting: Michael Cohen announced to the lkml his intention to begin a new 2.4 development tree. The first release of his -mjc branch includes a number of performance enhancing patches, including Robert Love's preemptible kernel patch, Rick van Riel's reverse mapping patch and George Anzinger's real time scheduler patch. Michael says of this patch, "I feel that there's need for a rapidly developing '-ac [like]' tree, and so, here we go. Feel free to test it""
That's a question I had, as well... isn't one of the big "selling points" about Linux the fact that there aren't branches and forks everywhere? The appearance of one may prompt the appearance of others. It may not confuse us, but corporates looking at Linux may be stumped by the sudden availability of several different "versions" of the 2.4 kernel. And it's the exact sort of thing that Microsoft loves to make fun of Linux for (I recall a German magazine ad directed against Linux. It showed the same animal 4 times, but each time it had a different head. The gist of the ad was "Code forking is bad, Linux can be forked, so ignore the Win9x/WinNT thing and use Microsoft.").
I think the terminology here should be used very carefully; these are patches to the official 2.4 kernel. Not kernel branches. Branches indicate disagreement between programmers (remember, corporate viewpoint here). Patches are just additions by independant groups, which is far more acceptable to the corporate mindset. I wouldn't make such a big deal of this, but this is a very delicate time for Linux. A lot of people are truly beginning to take it very seriously, and the one thing the Linux community needs to do is present a united front to the people inspecting it. Any indication, real or perceived, of internal turmoil will drive businesses (and individual users) away.
End of lesson. You may press the button.
Everyone knows Linux is the organized chaos. Anyway, this model of managing seems to be working pretty well. At least until now.
I think that, although it's always great to have many people working in parallel, it's not good to create more and more fragmentation (we already see this fragmentation in the dozens distributions out there). There'll be confusion and problems syncing the codes. Sometimes I think we're adopting an model that *WAS* great, but IMHO is not the best for the future of linux.
Exactly what I was thinking.
While we're at it, let's get _all_ of RML's patches into the _main_ kernel. Show your support by visiting here and signing the petition!
RML NEEDS YOUR SUPPORT!