Slashdot Mirror
New Linux Kernel Development Process
An anonymous reader writes "Releasing the 2.6.13-rc4 Linux Kernel, Linus Torvalds announced an improved development process to try and minimize the number of bugs in the kernel. The general idea is simple: changes will only be allowed for two weeks after the release of a stable kernel. All the rest of the time between releases will be spent on fixing bugs. This should improve upon last year's development module, which allows for active development in the 2.6 stable kernel."
It almost sounds like a normal sw dev process.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
This seems to put more pressure on individual distro vendors to add features and test them, then discuss their inclusion in the upstream kernel. Seems pretty reasonable to me. This should definitely stabilize the kernel a lot.
Proper English is:
try to minimize
not:
try and minimize
I'm just going for my dialy troll mod, since I seem to be getting many troll and overrated mods for posts that don't deserve them.
Two branches one a server platform and the other a desktop platform
Just make the kernal completely modular.
I was planning on submitting a patch to make a certain tablet pass pressure data to X. (By re-mapping Tablet-Pressure to Mouse-Z).
Now I'll have to rush to get it in without a huge wait before it gets in the main tree.
It means the longer you wait, the more stable the kernel will be.
No more lucky dips, and less need to depend on the vendors tracked patchsets.
Sam
blog.sam.liddicott.com
This has been discussed many times. You can configure your kernel to omit sound, v4l, etc. Even if you do compile these things, they won't be included in your running kernel unless you load the modules.
What you want can be done by removing sound and other desktop stuff from the startup services. Most distros have a friendly way to do this. No kernel recompile necessary.
When we're about to release a new version of our software, we only focus on fixing bugs and adding important requested features. And of course, there are the all-famous CVS branches. In any case I'm glad the Linux development process has taken this approach.
Linux has made amazing progress.
But as I browse the submitters of actual code, it seems that it's no longer the every-man's operating system.
More and more often we're seeing Red Hat and IBM employees tinkering with the code.
Does this mean a lack of quality? No, certainly not. A professional developer is usually very well versed in what he or she's working on.
But I propose that we watch what is being worked on and that our priorities are appropriate.
Perhaps an IBM or similar company has a new feature that they want, or worse, need, in the Linux kernel, and as such they spend all their time working on that.
The reality might be however that an improved VM is needed but all the Red Hat guys are busy working on some scheduling code that really isn't as crucial.
As far as I know, Linus himself still verifies all submissions and deems which baselines they appear in, but I hope that since he's also a professional and getting paid by Corporate if our priorities are straight.
Hopefully RM Stallman and friends are always heads-up, but I'm aware that often some serious fights take place on the Linux kernel mailing list regarding these types of issues.
Let's keep Linux progressing in the areas it needs to mature!
If you "get" pointers add me as a friend (116)!
This seems to work successfully for a number of open source projects, which use a version numbering system that allows users to tell at a glance whether they're using a development version.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
No need. The distros all ship modular kernels. If e.g. your server has no audio hardware, no audio drivers will be loaded. IMHO maintaining two separate kernel branches would be inefficient - and if two, why not a third, low-power kernel branch, and a fourth, router-optimized kernel branch? This road leads to madness, and we lose sight of the fact that the one general purpose linux kernel is flexible enough that it works pretty well on everything from embedded devices to gaming workstations to mainframes to supercomputers.
Assuming there is a valid case for a desktop performance oriented kernel and a server performance oriented kernel, the vendors could easily provide separate optimized kernel packages, built from the same source, but with different options. The desktop users want low latency for video, music and 3D FPS gaming, while server users want scalability and throughput...
In fact some vendors may already be doing this.
Didn't Torvalds once say something along the line that 'perfect is the enemy of good' when criticizing BSD? Is he moving away from 'good-enough' with lots of features constantly coming out, towards a more BSD-esque, move along slowly with stable-code philosophy?
I, for one, welcome our English-correcting overlords.
As long as the correction is done in a kind manner, this kind of stuff does nothing but help. I've learned a few things, at least.
More
As I think more about this decision, I wonder why not simply split the development between bug fixes and feature providers.
For example, Linux kernel 2.7 is released.
We run regression test on it for a week or two.
At that point, we document all known bugs and hand them and the entire 2.7 codebase off to our bug fixing team.
Then we identify improvements to current capabilities as well as new features we want to add, document all of it clearly, and hand that off to the feature team along with their own copy of the 2.7 baseline.
Then we have our bug guys working the 2.7_bugfix baseline and our features guys adding valuable new code to the 2.7_features baseline.
Prior to the next release, we merge all the changes together, spend a week sorting out any dependecy problems and interface problems, then we ship.
And repeat.
Sounds feasible to me. I just don't like the feeling I get when thinking that there's such a short development window.
The Linux kernel is already pretty darn stable, especially when compared to other operating systems. Let's keep the new features coming!
If you "get" pointers add me as a friend (116)!
I think you misunderstood the concept. A developer doesn't have 2 weeks to insert new functionality. A developer can work on enhanced performance or new features for 9 months, but there is a 2-week window after each release in which patches will be accepted.
The two things are orthogonal. Once the code has been thoroughly tested and a patch is ready it should be no problem for the core developers to email the patches to Mr Torvalds within that 2-week window of opportunity. I see no problem here.
Also note that they are going to try this approach. If it doesn't work out, I expect that Linus (ever the pragmatist) will drop it rather quickly...
This simply makes it so that bug patches don't get stepped on all of the time. Developers that are submitting feature updates will have to simply time their submittion. I don't think it'll slow development at all, it'll just polish releases more easily.
How about fixing the bugs that have been outstanding for well over a year?
It really is disappointing to spend hours testing and finding how to 100% reproduce bugs, even those that freeze the system as a user, report it to the various mailing lists, only for them to be ignored.
Yes, I've tried fixing some myself.
A developer doesn't have 2 weeks to insert new functionality. A developer can work on enhanced performance or new features for 9 months, but there is a 2-week window after each release in which patches will be accepted.
The two things are orthogonal.
We'd better hope everyone's patches are orthogonal too. If five Linux kernel developers all spend 9 months working independently on patches which turn out to make conflicting changes to the same subsystems, then after 2 weeks there will be one happy developer with his patch in the Linux kernel and four unhappy developers deciding whether to fork Linux or switch to FreeBSD.
Of course, to avoid such problems we can assume that those many different kernel developers are not working independently, but are committing changes to a single unstable kernel to share those changes and prevent conflicts. In that case, let's just call the new unstable kernel "2.7" and return to the system that was working so well for years.
2.6 has been one big regression fest, and despite its advantages I've always had to use something else for anything but desktop duty because the risk was too high.
There has to be a tradeoff between new features and sufficient stability to contemplate using the new features -- they aren't an advantage if they are inseparable from the bugs.
Glad Linus came around.
I rarely criticize things I don't care about.
I have them turned off and I didn't see his add. It also makes slashdot a hair less annoying.
Actually there are a couple of basic facts to mitigate the concerns you cite above:
First of all, the developers tend to have really good communication among themselves, they know each other, and the developers know what other developers are working on. Some random john doe who appears out of the blue one day with a huge patch is not about to get his work accepted. It's also common sense to submit a patch against the current tree, not something from 13 versions ago.
Secondly, Linus uses a system to manage all these potentially conflicting changes. (For several years until just recently, bitkeeper was used to manage patches to the kernel tree - now that function is being filled by a tool called git, a version control system developed by Mr Torvalds)
In any case, these things have been thought through.
I remember when the Linux kernel was rock solid, stable and reliable. I remember when there were no huge code changes in the "stable" even-numbered kernel series. Remember those days? I'm talking late 2.2.x before the whole VM debacle in the first part of 2.4.x.
In the last few years, it seems the push to carve out marketshare on the desktop has been fuelling kernel development more so than server-oriented work. I've been frustrated to the point of recommending Linux-kernel-based systems only with caution and caveats, preferring instead Solaris for serious enterprise-level server-side work.
If this works out, it'd be a boon for enterprise adoption of the Linux kernel. Hats off to Linus et al. for this change in their practices.
--rc
In British usage, either spelling is correct, although I think that the -ise spelling is more common: it also tends to be the form used by official publications.
The Oxford Dictionary has always preferred -ize, although this is more through tradition and stubborn prescriptivism than anything else. (And maybe the fact that one of the original edition's most prolific contributors was the American murderer and lunatic William Chester Minor, then detained in Britain, might have had some small part to play.) Older editions of Chambers, on the other hand, preferred -ise to the extent of not even acknowledging the -ize variant.
I think that the strong desire to differentiate British usage from its colonial counterpart has also led to an increase in the usage of -ise, in an analoguous process to that in which Noah Webster attempted to Americanise the US orthography for political reasons.
If your comment title says 'Re: Foo', I'm not likely to read it.
when someone trolls and notes that they'll get "unfairly" moderated for it, the usual response is "informative" . . . whehter it's trollish, informative, both, or neither . . .
hawk