![Linux Linux](http://a.fsdn.com/sd/topics/linux_64.png)
![Software Software](http://a.fsdn.com/sd/topics/software_64.png)
New Linux Kernel Development Process 207
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."
talking not enough (Score:4, Funny)
Who'da thunk it (Score:2, Interesting)
Re:Who'da thunk it (Score:2)
Hahahaha. You've never worked in a real software development company, have you? Let me break down the process for you:
1. Code furiously, creating bugs and features.
2. Tar up the development tree, drop it into place for release.
3. Perform steps 1 and 4 in parallell.
4. Fix bug in main development tree.
5. Perform steps 1, 2, 3, and 4 in parallell.
I think that about covers it.
Re:Who'da thunk it (Score:2)
Re:Who'da thunk it (Score:2)
Re:Who'da thunk it (Score:2)
Just turn off sigs. (Score:3, Informative)
Interesting (Score:5, Insightful)
I'm guessing... (Score:2)
Problem is, those soft freezes never worked well when we had them for the year-plus cycles, so there's no reason to assume they'll work well for the spin-cycles.
Having said that, anything that encourages rapid development AND a clean stable version has to be a good thing, whether the developers sti
Troll this (Score:2, Informative)
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.
Re:Troll this (Score:2)
Re:Troll this (Score:2)
" I seem to be getting many troll and overrated mods for posts that don't deserve them."
no, no, no (Score:3, Informative)
hawk
Re:Troll this (Score:2)
I thought it was "trawling"?
Ah, I've learned something. "Trawling" can refer to this, but also to dragging a wide net (which is what I had in mind). "Trolling" can mean however to fish by dragging a baited line.
-b
Re:Troll this (Score:2)
Re:Troll this (Score:2)
I find grammar blitzkreigs usually peter out in the barbarossan wastes of the illiterate "(my) usage is king". OS jihads never end. But I don't metamod "Troll", because, like all expression, trolls are best fought with cogent, honest, direct reponses. Or withering sarcasm. Other people can still learn from trolls, even if the two parties merely stalemate in flamewar. One poster's "Troll" is another poster's "FAQ" (or FAWQ - "Wrong").
Re:Troll this (Score:2)
1) 'try' the bugs (test them, put them under trial)
AND
2) 'minimize' the bugs (attempt to reduce the number of the bugs which you have tested).
So, while I agree that it's statistically likely that he intended to say what you think he meant - his sentence is still grammatically correct if you interpret it the way I've suggested.
Cheers!
MOD PARENT INFORMATIVE (Score:3, Insightful)
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.
Re:MOD PARENT INFORMATIVE (Score:3, Informative)
Re:MOD PARENT INFORMATIVE (Score:2)
Re:MOD PARENT INFORMATIVE (Score:3, Funny)
Re:MOD PARENT INFORMATIVE (Score:2)
Here's some information:
http://alt-usage-english.org/excerpts/fxtryand.htm l [alt-usage-english.org]
http://www.randomhouse.com/wotd/index.pperl?date=1 9960612 [randomhouse.com]
http://englishplus.com/grammar/00000253.htm [englishplus.com]
The answer is (C) either of the above (Score:3, Interesting)
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.) Ol
I'd better get my butt in gear (Score:2, Insightful)
Now I'll have to rush to get it in without a huge wait before it gets in the main tree.
Re:I'd better get my butt in gear (Score:2)
Re:I'd better get my butt in gear (Score:4, Informative)
Of course, the right way to get a change made is to get it into -mm now (or whenever), and have it working there; then it'll get tested and accounted for in other development, and will get put in by default at the start of the cycle if there's been good feedback. Then you just have to test it in -rcs and report if it gets broken.
Good because... (Score:4, Interesting)
No more lucky dips, and less need to depend on the vendors tracked patchsets.
Sam
Not quite (Score:2)
Re:Not quite (Score:2)
This is called "Feature Freeze" (Score:2)
Linux no longer a blue-collar kernel? (Score:2, Insightful)
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
Re:Linux no longer a blue-collar kernel? (Score:5, Funny)
Re:Linux no longer a blue-collar kernel? (Score:5, Funny)
Re:Linux no longer a blue-collar kernel? (Score:2)
Re:Linux no longer a blue-collar kernel? (Score:2)
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.
All this means is that these companies are now paying people to work on Linux instead of hack on it in their spare time. There's even people with @microsoft.com addresses in the contributors file.
Linus verifies most submissions in the dev kernel, but he often does it now as merges from someone else's branch, instead o
Re:Linux no longer a blue-collar kernel? (Score:2)
I should probably mention that those folks are almost certainly still "spare timers"
It's GPL'd (Score:2)
Re:Linux no longer a blue-collar kernel? (Score:5, Informative)
Regards,
Steve
Re:Linux no longer a blue-collar kernel? (Score:4, Insightful)
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.
If an improved VM is needed, then who needs it? Why would there not be anybody to "scratch that itch" if people need it? The presence of large companies contributing scheduling code does not mean that other people can't contribute VM code.
But I propose that we watch what is being worked on and that our priorities are appropriate.
From your post, I suspect what you mean is that you want Redhat's priorities to be appropriate for your needs. Free Software isn't about getting other people to do what you want.
If there's nobody contributing code that satisfies your needs, then perhaps the rest of the world doesn't consider it as necessary as you do, in which case, you have an unusual problem and you know exactly what you can do to fix it - code it yourself or pay somebody else to.
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.
That sentence doesn't make sense.
Re:Linux no longer a blue-collar kernel? (Score:2)
That's fine, because an improved VM can only really be done by developers who have specialized in the VM, not the people working on scheduling code. Practically all of Linux is to the point now that you can only improve it if you have some special qualification (which may be just that you have the hardware you want a driver for, or might be a lot of experi
Re:Linux no longer a blue-collar kernel? (Score:4, Insightful)
It's no different than any other open source project. If I want something in slashcode, I code it according to my interests. In linux, big features are coded according with the interest of vendors. There's not a really big difference. Look at the poor state of graphic drivers in linux for example - if that was important for vendors we'd have great graphic drivers
Re:Linux no longer a blue-collar kernel? (Score:3, Insightful)
>employees tinkering with the code.
And it never occured to you that RH/IBM are *hiring* kernel developers?
>The reality might be however that an improved VM is
>needed but all the Red Hat guys are busy working on
>some scheduling code
Well, if a new VM is needed, i'm sure someone will work on it (at least the people who need it, right?)
If you also get better scheduling code, i don't know seems like a good deal for me...
>since he's also a profess
One concept I heard that I kind of like... (Score:4, Interesting)
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.
Re:One concept I heard that I kind of like... (Score:3, Informative)
Re:One concept I heard that I kind of like... (Score:3, Informative)
It was supposed to decrease the amount of backporting, and increase the available testing.
First, as new features (and drivers) were added to the development tree, people backported them to the stable branch, this supposedly drew efforts away from the development tree (ie. people were spending time backporting the new features/drivers when they could be debugging/testing the development tree instead.)
Second, as the develop
Re:One concept I heard that I kind of like... (Score:2)
Re:One concept I heard that I kind of like... (Score:2)
Re:One concept I heard that I kind of like... (Score:3, Informative)
Re:One concept I heard that I kind of like... (Score:2)
Re:One concept I heard that I kind of like... (Score:2)
a philosophical contradiction? (Score:5, Interesting)
Re:a philosophical contradiction? (Score:5, Insightful)
Which is also, btw, what people say they want from MS and Windows.
Re:a philosophical contradiction? (Score:2, Interesting)
Re:a philosophical contradiction? (Score:3, Interesting)
Re:a philosophical contradiction? (Score:2)
But then, my CD drive is on a Promise card because Linux can't use it when it's connected to the motherboard anymore.
It's not just a few pesky little bugs, it's huge crippling regressions, and I don't even want to upgrade because who knows what will bite me next time. At least I have a Promise card so I can work around the bugs in my current version.
2.6 is very close to being unusably bad. To me, the only cases where it's acceptable are where stability doesn't ma
Re:a philosophical contradiction? (Score:5, Funny)
If only we could have it both ways. If only there was some way that folks that needed stability could have some kind of stable Linux kernel, while folks who wanted to experiment with the latest and greatest features could have some kind of experimental kernel.
Perhaps we could use some kind of numbering scheme that separated the two; for example using "odd" version numbers like 2.7 for the experimental kernel series and even numbers like 2.6 or 2.8 for the stable series. One might imagine that periodically the matured changes in the experimental series could be merged back into the stable series, starting new series for both stable and experimental.
Maybe Linux should have instituted a process like this years ago. Then they'd have some experience with it by now, and could have it running smoothly instead of messing around with new development processes like they currently are.
Oh well. Just a crazy dream I had.
Re:a philosophical contradiction? (Score:2)
Re:a philosophical contradiction? (Score:2)
Re:a philosophical contradiction? (Score:2)
Re:a philosophical contradiction? (Score:5, Funny)
Re:a philosophical contradiction? (Score:2)
One word:
BitKeeper.
Re:a philosophical contradiction? (Score:5, Insightful)
Linus says a lot of things. It seems to me that he is just using the scientific approach, and trying new ways of doing stuff to see what works best. Some ideas are good, others are bad. But if you never change your process, you'll never find out.
These changes in the process make a lot of people scream whenever they happen. That's because people doesn't like change. Even now, people are screaming about breaking the odd/even process (which didn't work too well), even though the 2.6 process has worked much better. If the 2.6.13 process isn't even better, Linus will scrap it and try something else (such as going back to the old 2.6 process, or the 2.6.x.y process, or something else new, or whatever).
Stay calm! The world isn't going to end! All these changes mostly affects kernel developers, and even then, mostly those in the "inner circle". Your redhat/ubuntu/suse/whatever will still work just fine.
Re:a philosophical contradiction? (Score:3, Insightful)
What linus has really said in the past:
"I retain the right to change my mind, as always. Le Linus e mobile."
"And don't get me wrong - I don't mind getting proven wrong. I change my opinions the way some people change underwear. And I think that's ok"
Re:a philosophical contradiction? (Score:2)
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 wouldn't say that. It used to be that active kernel development took place on odd kernel numbers (2.1,2.3,2.5), and bugfixes only happened in even kernel numbers. This has changed recently due to odd branches not being tested enough by distributions. Of course this leads to instability in the kernel because new untested stuff is "dangerous".
This move
Re:a philosophical contradiction? (Score:2)
It may be decided in the future that the new system can't handle radical new changes the way the old system can. This is the most likely scenario for going back.
time for 2.7...? (Score:2)
let's start hacking again
My gut tells me this is a bit extreme (Score:5, Interesting)
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!
Re:My gut tells me this is a bit extreme (Score:2, Funny)
to stop pressing the retun key
As much as you have been.
It gets really annoying.
I mean it.
Re:My gut tells me this is a bit extreme (Score:2)
Re:My gut tells me this is a bit extreme (Score:3, Insightful)
Now if you mean handing it to a QA team, that sounds fine.
Two details to note (Score:5, Informative)
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 won't slow development much. (Score:3, Informative)
Here's an idea! (Score:3, Insightful)
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.
about time (Score:4, Insightful)
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.
Re:about time (Score:3, Insightful)
Dude, how often do you need to repeat yourself?
You made no less than 4 posts to this thread, all saying the same thing.
Yes, 2.6. is not quite stable but at the same time it's not as bad as you make it sound.
I wouldn't use it on a server but for most workstation- and home-use
it's pretty fine already!
It seems you have missed that 2.6 is the head-branch.
That means it's a work-in-progress and nobody considers it finished!
So just quit the whining and stick with 2.4 until 2.6 i
Re:about time (Score:2)
open to criticism.
I feel the 2.6 philosophy has been damaging to Linux, and I have as much of a right to criticise Linux as the yes-men have to praise it.
Re:about time (Score:2)
Not that alone, but there are other examples that have happened to me. Examples from others are equally abundant. Congrats if you've been lucky.
There was that memory leak that prevented burning from working, I've had DMA quit working on any non-SATA drive, I can't set the MTU on my network card. I believe the fact that I don't have more examples is a result of me giving up on new kernel versions and using the Debi
Better have more rapid releases then... (Score:2)
1) Is the driver system in linux mature enough that it is ABI-stable? Do you need to continue to have that many features added if drivers can be added easily by distros?
2) What features are still being added to the kernel that aren't drivers? Are they that exciting that you can't wait.
3) Will it re
Full kernel summit coverage (Score:2)
This is GREAT news (Score:5, Interesting)
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.
Re:This is GREAT news (Score:2)
Yeah, I remembered those days as it was yesterday. In fact it actually WAS yesterday that I logged in to a rock solid Red Hat AS 3.0 box.
What are you blabbering about, man? It's the task of the big distro's to take a stable kernel and keep it stable.
You don't do kernel downloads/compiles yourself and put them in productio
First 2 weeks for development = only 2 weeks in cy (Score:2)
We can just release a new kernel every 2 weeks and spend all our time adding features!
Here's an idea... (Score:2)
While I'm wishing for ponies, could the bugfix-only release also have a stable ABI, pretty please?
Don't stop there... (Score:2, Funny)
Just make the kernal completely modular.
Re:Don't stop there... (Score:5, Informative)
Re:Splitting it (Score:2, Informative)
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.
Errr... (Score:2, Redundant)
Two different things you're talkin' 'bout here. Now, most main stream distros have just about everything included as modules, except system-critical stuff, and then use various means to detect your system hardware and load the modules needed.
uh...word.
They already have: (Score:2)
Re:They already have: (Score:2)
Re:Splitting it (Score:2, Funny)
YEAH! Oh HEY, maybe you could even make all the drivers available as separate modules, and that way anybody could include anything they want, and remove anything they don't want.
Re:Splitting it (Score:3, Interesting)
Re:Splitting it (Score:2)
Re:Splitting it (Score:2)
Re:2 Weeks (Score:5, Interesting)
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.
Re:2 Weeks (Score:5, Insightful)
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.
Re:2 Weeks (Score:3, Informative)
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
Re:OT: Slashdot main page (Score:2)
Re:Can anyone tell me... (Score:2)
You're lucky.
They're usually "stable" in that they don't crash, but they're "unstable" in that things like drivers mysteriously stop working in each new release. A release will usually fix previous bugs, but it will also bring with it a whole new set of regressions that can be crippling.
Every OS does that, but the risk on Linux 2.6 was absurd.
Re:Can anyone tell me... (Score:2)
The time you have to go to kernel.org kernels or kernels built for your distro but not in the stable releases of the distro itself is when you have new or obscure hardware that your distro kernel doesn't get along with. Unfortun
Ooh! Ooh! Fresh eggcorn! (Score:2)
This is a new one for the Eggcorn Database [lascribe.net], I think.