Slashdot Mirror
Linux Kernel to Fork?
Ninjy writes "Techworld has a story up about the possibility of the 2.7 kernel forking to accomodate large patch sets. Will this actually happen, and will the community back such a decision? "
← Back to Stories (view on slashdot.org)
The Linux kernel forks all the time. 2.5 was a fork of 2.4 when big patches couldn't be merged otherwise. This is all terribly normal, the article was obviously written by an uninformed outsider. 2.6 will fork into 2.7, which most people wont use while big changes are made, and eventually 2.7 will become 2.8, and then for a while there will be one version. Until the next "fork," also known in Linux land as a "development version."
I want my Cowboyneal
You don't understand. A package manager is a piece of software that does resolve dependency, download packages (from the Internet or local media) and install them for you. That is why they are called package manager. Using these, you never have to "chase" down package, it's all automated. There are many of them : apt, yum, up2date, urpm, emerge, etc.
Please get current instead of making a fool of yourself on the Web; this problem have been solved a few years ago. Your favorite distro probably use one, and you don't even know. Which one is it, anyway, so I can give you the executive summary on it's usage ?
:wq
I notice a number of posts indicating that this is just pure uninformed journalism but is it? Or is he actually just blowing up a different related issue out of proportion.
In the Linux Kernel Development Summit back in July, the core developers announced they weren't creating a 2.7 development kernel any time soon (discussed here and here).
Developers liked the way things were going with the new BitKeeper in use by Linus and at the time, they didn't see the need to fork a 2.7.
Traditionally before BitKeeper, kernel maintainers would send Linus 10-20 patches at once, then wait for him to release a snapshot to determine whether or not the patch made it in. If not, they would try again. During the 2.5 development cycle, problems started over dropped patches and that is when Linus decided to try BitKeeper.
According to Greg Kroah-Hartman, kernel maintainer, Bitkeeper has increased the amount of development and improved efficency. From 2.5 and 2.6, they were doing 1.66 changes per hour for 680 days. From 2.6.0 to 2.6.7 they were at 2.2 patches per hour thanks to the ability of wider range of testing of patches that went into the tree. The new process is - 1) Linus releases a 2.6 kernel release. 2) Maintainers flood Linus with patches that have been proven in the -mm tree 3) After a few weeks, Linus releases a -rc kernel 4) Everyone recovers from a load of changes and starts to fix any bugs found in the -rc kernel 5) A few weeks later, the next 2.6 kernel is released and the cycle starts again.
Because this new process has proved to be pretty efficient and is keeping mainters happy, it was predicted that no new 2.7 kernel was to be forked any time soon unless a set of changes appeared big enough and intrusive that a 2.7 fork is needed. If that is the case, Linus will apply the experimental patches to the new 2.7 tree, then he will continue to pull all of the ongoing 2.6 changes into the 2.7 kernel as the version stabilizes. If it turns out that the 2.7 kernel is taking an incorrect direction, the 2.7 will be deleted an deveryone will continue on the 2.6. If 2.7 becomes stable, it will be merged back into 2.6 or will be declared 2.8.
In conclusion, there was no plan for a 2.7 any time soon thanks to maintainers working well in the current setup but this was not carved in stone. It might just be that big enough changes are calling for a fork.
[alk]