Slashdot Mirror
2.6 and 2.7 Release Management
An anonymous reader writes: "A recent discussion on the Linux kernel mailing list debated whether the upcoming 2.6 and 2.7 kernels should be released at the same time instead of first stabilizing the 2.6 'stable tree' then branching the 2.7 'development tree.' The theory behind the proposition is to keep "new" things from going into 2.6 once it is released, focusing instead only on making it stable. On the flip side of this argument is the possibility that with a 2.7 kernel in development, there will be too little focus on stabilizing the 2.6 kernel.
The resulting debate makes for an interesting read."
there will always be a kernel in development and one being stabalized.... its a wash either way.
i would recommend the stabalization of 2.6 before the branch of 2.7 (the initial arguement) and i think the flip side is incorrect... just because 2.7 is 'in the works' doesn't mean that the 2.6 hackers are going to take a nap on their work
MARIJUANA, SHROOMS, X: ONLINE?! - E
I would release them at the same time. Just as now, with 2.4 and 2.5, there are people who are very good at stabilizing current code, and people very good at developing new code. Some folks can't stand working on new things when the old need work, and vice versa.
I see this as having two benifits. First, it will help with the ``Most things work pretty well---let's go ahead and release it.'' attitude. The 2.4 series has only recently gotten stable enough to reliably use in a production environment, and not everyone agrees on that even.
Second, it will allow people to focus on what they are good at. The 2.6 series will mature much faster without adding new features in every release. Sure, there are bound to be a few gotchas, but if the focus is on stabilizing the code, they will be out by the 2.6.3 or 2.6.4 release. At the same time, people will be adding to 2.7, which should mean that there is much less time between stable kernel series releases.
I'm all for it!
--Wyatt
Karma: Marginal (mostly due to the border around the website)
See, to me when someone calls it a "stable release", that means it's already been stabilized. Sure, you're going to have the occasional bug fix here and there, but actual "stabilization" should've been done in the 2.5.99 range, ie. the previous development branch. Once the stable tree is released, there shouldn't be a need to stabilize it and branching the new development tree right then makes sense. There should not be an "development" per se in the stable release after that, only the occasional maintenance.
.0 release of the kernel.
If the kernel maintainers would just grasp this one simple point, maybe this issue wouldn't be one, and maybe people wouldn't laugh at the
From the bsd world, there is the concept of "backport" which is where a feature in the development kernal is ported back to a previous stable kernal series.
Great for bug fixes, and other things in the middle ground.
Certainly if there is interest, a set of patches to a stable kernel, or even another -someone kernel series can be developed. If these turn out to be in demand, and stable enoug, they can be officially included.
A large reason for the awful VM mess that 2.4 was in around 2.4.8 - 2.4.11 or so was largely due to the fact that a totally new VM was just kind of "thrown in" to the "stable" branch, probably mainly cause there wasn't a 2.5 branch yet at that point (as I recall). This is the sort of thing that branching earlier would hopefully prevent. While the stable branch may not have some of the "bells and whistles" it could have gained from keeping the branches together, at least hopefully a mess like that can be avoided.
Then again, that's just my opinion :)
The linux kernel,. besides stability .. what sort of things do they want top add/improve?
.. such as being able to allocate how much CPU, memory, or disk space a particular user or process can use. These are things that solaris has had for a long time .. and it seems that linux kernel developers arent interested in adding those features .. how can linux hope to take over the enterprise server market without it?
better networking? better I/O performance?
what about multiple CPU support?
The most important thing for me would be resource management features
Does anyone have any info on what's happening in the area of adding resource management features to the linux kernel?
Actually any info on what cool features they are working on for future releases would be appreciated
...would be a good idea IMHO if this kept Linus away from working on the stable branch.
Look at what happened with 2.4, we had the change to VM, 2.4.11 which needed immediate patching and is tagged as dontuse, 2.4.13 similar problems, 2.4.15-greased-turkey released by Linus for Thanksgiving and a nice syncing problem.
When it comes to deciding what is and is not allowed into the kernels the buck stops with Linus. This is why I think Linus should stick with the development kernels where a major change can have all its kinks worked out in relative safety. The stable branches should be maintained by someone who only has authority to accept and apply bug fixes.
I've got a fever and the only prescription is more COBOL.
Most of our opinions on this really dont matter. I have run unstable kernels for a long time and never had any trouble with them. The only time it is really an issue is with production servers, which most of us dont run. I think those of us who dont run production servers should refrain from submitting our opinion and leave the line clear for those who it really affects.
Im not here now... Im out KILLING pepperoni
If 2.7 begins before 2.6 is stable aren't we in danger of seeing a win9x syndrome in that bugs will live for ever and instead of being fixed they will be coded around. I fear very much the long term affects on the kernel and in turn Linux if the trees are split prior to a stabilization period. I am a developer, not on this level, but I have seen the affects of splitting a code base simply to continue developing and at the same time trying to patch existing "production code" and then port things back and forth. It is a very bad idea!! Usually what happens is things don't get back ported they are only provided doing a major upgrade, again the microsoft way of bug fixing.
Granted, you will always have some cross patching, however I think the idea of building off of a clean base is very important. For example, you would not put new tires on your car if the engine is not running, right?
Essentially, I think the issue here is one of knowing the base is clean versus drudging on in the dark despite the fact that you have been offered a lantern.
To put this most bluntly I would call this Microsoft syndrome. As I said before win9x is the perfect example of a system that was never stabilized rather it was constantly released to the unsuspecting public as upgrades which where really bug fixes and the monkeys went back to the keyboards never addressing issues raised by numerous consumer requests on the so called production release because the devel team would rather work on that new feature because it is more interesting than maintaining the existing code base.
I am being harsh here I know, but I am trying to view this in the long term. I feel that this would weaken the kernel and as I said weaken Linux which would in the end at least decrease corporate trust in the stability of Linux or at worst give M$ what it wants, Linux's death,
Maybe I am extreme, feel free to beat me but I know you have to have a clean starting point before you can move forward otherwise you will constantly be taking steps backwards which eventually leads to stagnation and death.
Just my thoughts
Release version 2.71828 and call it quits.
Marcelo got into kernel hacking when he was like 16. So what if our current Gods decide to leave? They would be missed, for sure, but there'd surely be someone new, hungry, and just as skilled ready to take their place.
That's why Linux can be counted on. NT4? MS just up and decides to drop support. Interactive Unix? Sun just up and decides to drop support. Thank god IBM has kept up with OS/2..for now..
So, the best time to let 2.6 "escape" is when you're fairly confident it's "ready" and won't need patching.
Of course, you'll be wrong -- it will need patching, or backports of useful features that just didn't make it in time.
But, the idea is that these patches or backports should be trivial "oopses" where the change does not require massive code review, or the backport is clearly something that was "99% done" already.
So, my suggestion is release 2.7, and hold off on release 2.6 until the obvious release-related "oops"es are found, say 1-2 weeks, then try your best to release a 2.6 that won't need patching. It will anyway, but don't lose sleep over it.
You could've hired me.
Anyone who runs production systems expects (demands?) even-numbered releases to be stable.
There's no serious linux admin out there that wants to have to test a new supposedly "stable" kernel for a week before employing it on a bunch of mission critical boxes. Say I want/need a feature in the new release of the "stable" kernel, should i expect anything less that a kernel that is rock solid? There's people still running 2.2 series kernels because of the whole 2.4 feature creep fiasco.
All the stability issues should be worked out before a kernel is considered "stable." Seems to make sense to me...
Unstable series often start off with versions which break everything, because whatever fundamental change is first up for the series has gone in and the drivers and so on haven't been updated. It was a long time in 2.5 before it was really sensible for people to work on it (aside from the bio work), and people were actually doing their development on 2.4 even after 2.5 had started. In part, this wasn't even an issue of stability: Linus just wasn't taking patches on other subsystems. If 2.7 starts when 2.6 comes out, and major changes go into 2.7.1, people will stay on 2.6 until the first major set of changes in 2.7 has stabilized. Provided that the first thing under development in 2.7 isn't broken in 2.6 (in which case, the people who could fix it would be working on 2.7), everyone important to fixing obscure bugs in 2.6 will still be working on 2.6, but sitting on their patches, because they can't go into 2.6 (not fixes). As the interfaces for 2.7 (where they differ from 2.6) become known, people will start using them, but, until that point, 2.6 and 2.7 are basically the same, except that you can get 2.6 running to develop on.
[ ...Putting on my "politically incorrect" hat... ]
It's a common Open Source Software problem: there is the last release, and there is the developement branch.
Developers would all prefer that you use the developement branch, report bugs against *that*, provide patches for the bugs against *that*, do all new work in the context of *that*.
But it's not how things work, outside of an Ivory Tower.
In the real world, people who are using the system are using it as a platform to do real work *unrelated to developement of the system itself*.
I know! Unbelieveable! Heretics! Sacreligios!
FreeBSD has this disease, and has it bad. It very seldom accepts patches against it's last release, even in the developement branch of the last release, if those patches attempt to solve problems that make the submitted work look suspiciously like "developement". The cut-off appears to be "it fixes it in -stable, but would be hard to port to -current; do it in -current, as your price of admission, and back-port it instead, even if you end up with identical code".
The only real answer is to keep the releases fairly close together -- and *end-of-life* the previous release *as soon as posible*.
The FreeBSD 4.x series has lived on well past FreeBSD 4.4 -- supposedly the last release on the 4.x line before 5.0. FreeBSD 4.6 is out, and 4.7 is in the planning stages.
It's now nearly impossible for a commercially paid developer to contribute usefully to FreeBSD, since nearly all commercially paid developers are running something based on -stable. FreeBS -current -- the 5.x developement work -- is *nearly two years* off the branch point from the 4.x -stable from which it is derived.
Linux *MUST* strive to keep the differences between "this release" and "the next release" *as small as possible*. They *MUST* not "back-port" new features from their -current branch to their -stable branch, simply because their -current branch is -*UN*stable.
Delaying the 2.6 release until the 2.7 release so that you can "stabilize" and "jam as many 2.7 features into 2.6 as possible" is a mistake.
Make the cut-off on 2.6. And then leave it alone. People who are driven by features will have to either run the developement version of 2.7, or they will simply have to wait.
Bowing to the people who want to "have their cake and eat it, too" is the biggest mistake any Open Source Software project can make.
Don't drag out 2.7, afterward, either... and that's inevitable, if everything that makes 2.7 desirable is pushed back into 2.6. Learn from the mistakes of others.
-- Terry
Kernels don't get truly stable until you get thousands of people using them, but all those thousands of people aren't going to install a kernel until it's deemed a stable release.
Release candidate kernels help alleviate this somewhat, but you can never really duplicate what happens when the bulk of normal users stand using it on an everyday basis.
Would starting the new development branch immediately after the stable release help? Hardly. It's the time when a lot of work has to be done on the stable branch.
But what if we make sure that the stable kernel is indeed stable when it's released, not after the "stabilization"? The only solution to make kernel stable is to test it a lot before it's released.
I don't think we should be afraid of "debian syndrome". Kernel is much more monolithic than a disribution, and if e.g. IDE doesn't work well, it takes much more efforts to downgrade it safely compared to downgrading e.g. Mozilla.
The fundamental problem with the development branch is that issues with one part of the kernel affect all developers and testers. If I e.g. want to test ACPI and know how to fix it, but I don't know how to fix IDE, I won't test the latest 2.5 kernel.
I believe that the best solution would be to have branches for different subsystems. IDE changes would be merged to the trunk only when they are stable enough for other developers. It's important that the development on the branches is done openly, step by step, so that an interested developer could find the exact place where a bug was introduced. But this style of development doesn't require doing everything in the trunk. In fact, to keep the kernel relatively stable the development should be done on specialized branches.
More stable development kernel would mean more testers. More testers would mean stable release, which is truly stable, at least compared to 2.2.0 and 2.4.0. And that would eliminate the need to force developers on stabilizing the branch that is supposed to be stable form the beginning.
4. The enter beast was so unyeilding, it was known that the only one person who ever understood it, had to keep a journal just to keep track of the beast (Seriously). This was one of the major reasons that ticked off Linus and I believe the reason why he pushed the new VM.
what is the "enter beast"?
cpeterso
Just a note, Windows 2000 GUI crashes an average of 6 times every 6 hours in my experience,
:-D
:(
/somewhat/ understandable API running underneath things? Hell, if even MS can admit that GUI APIs are a not going to be gotten right the first time, certainly the OpenSource community can admit to the same thing and do it again until it IS gotten right. Yes it would be a lot of work, but it would be worth it. (and had somebody started back in 1999 or so it might be nearly complete by now....)
Nice math their buddy, that is called once an hour....
Granted I had Windows 2000 core dump on me ~10-12 times yesterday (w00t) and another good 3 or 4 unexplained crashes, but that is all because I have managed to fuck up the DirectX sub layer to hell and well, err, heh;
when it IS running properly (which it will be as soon as I manage to find the install disks. ^_^ ) it has very long uptimes, though it is awfully dependent on what you are doing. After the first 3 or 4 hundred program installs/uninstalls things to tend to, err, get a bit cluttered, heh.
Then again I would like to see you do that many program installs in as short a time on a *nix box.
Bah, what am I saying, dependencies suck period, no matter what OS you are on.
Oh, and the *nixs DO have a shitty ass GUI system, seriously, there needs to be a BIG effort to ditch X and get a real system underneath that, technology has advanced a lot in the intervening years since X came out, hell, just the pure CS theory stuff has advanced a good deal, for crying out loud, come up with a better system. Or at least a more coherent one. It has taken MS how long and how many revisions/API changes to get even a
Need help treating your acne? Come here!
Couldn't the problem be solved by brancing the unstable first, then releasing the stable branch when it's ready?
For example, let's say that we're happy with the feature set in the 2.5 unstable series. Instead of putting off waiting for all of the bugs to get shaken out and call it 2.6, just switch from 2.5 to 2.7 on the unstable development side. Linus can pass the reins off to someone he trusts, we can have a GROF (Get Rid Of the Fin) party and his trusted lieutenant can finish stabilizing 2.5 into 2.6 without him.
This solves the problem of wanting to keep back-porting features from 2.7 into 2.6, it allows for time to make sure the 2.5 code is stable before public release as 2.6, and provides a clear feature-freeze mechanism: once Linus is gone, go bugfixes only. If you want the new features, run the unstable kernel or wait for 2.8 (released sometime after 2.9 is branched).
Not that my opinion matters at all, it's just an idea.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
Okay, what stable is, really? What does it mean to release 2.6.0?
To me, 2.6.0 means "okay, this is what we can possibly get if only developers are running the code. We have tested our kernel, we have high confidence that it will work for you, but, you know, there are surprises. So do try it out, if you can. We promise that if you find problems and tell us, we will put you to the highest priority, so that you don't have to fall back to 2.4.XX."
What is 2.7.0? People says that it means "okay, now we have 2.6.Y stable, we can pretty much ignore it. Let's put it in the hand of Xyz Abc, the new maintainer of 2.6 series, and new work will be placed at 2.7.ZZ". But I don't like this view. This ignores the possibility that new thing can land directly into 2.6.XX. This happened quite frequently in 2.4.XX, actually, and it does work.
I believe the real reason for 2.7.XX is that "after some use, we find that 2.6.XX has the following stupid problems. It can also be improved if we don't do things this way, but instead do things that way. But they are so fundamental to 2.6.XX, that if we ever change it, we can no longer make the claim that we made when we roll out 2.6.0. These things really needs to be done, though, but we prefer people not to use it yet, and we developers will try to make things work again after they break, and after every developers can reasonably make the claim we made when we delivered 2.6.0, we will roll out 2.8.0, when every of you can try this new neat way of doing things. Currently, please stick with what we have in 2.6.XX."
If that reasoning can stand, then what 2.7 is for is really new API. A new one that can cause everything else to break. I'd say, once we know what new API we want to create, we should create 2.7.0, *regardless* of whether 2.6.XX is stable enough or not. It is absurd to be afraid that stablization of 2.6.XX will slow down because of the existence of 2.7.YY: preference is always given to 2.6.XX if things go wrong there. The real problem to release 2.7.0 too early is that many things get implemented too quickly, when most of the API changes are still up in the air, forcing most things to be written again, perhaps for many times. When that "up-in-the-air" problem goes away (or has settled to a point that we want to write and see what will happen if we really do things in the new way), there is no excuse not to release 2.7.0. Further delay only makes sure that the next kernel will arrive late again.
After the first 3 or 4 hundred program installs/uninstalls things to tend to, err, get a bit cluttered, heh.
:-D
:-)
Then again I would like to see you do that many program installs in as short a time on a *nix box.
So, let's see if I got this right. You install a lot of stuff, the box goes bad. And you can install a lot of stuff a lot faster in windows than in an *nix box.
Therefore, the primary attraction in Windows is that you can muck it up one HELL of a lot faster.
Efficiency, in other words.
Yep, I'm with you
Blearf. Blearf, I say.
So, let's see if I got this right. You install a lot of stuff, the box goes bad. And you can install a lot of stuff a lot faster in windows than in an *nix box.
:-)
:-D (yah so darn nearly everything else about it may have sucked, but at least you could turn the computer on and know you'd get to something and be able to run something! If one app went down it didn't take nothing else with it.))
Therefore, the primary attraction in Windows is that you can muck it up one HELL of a lot faster.
Efficiency, in other words.
Yep, I'm with you
Well, thing is, I would like a setup (out of the box, I know I could just keep sequential images of my HD on a RAID array someplace on an older machine or such, but, err, that is NOT exactly eloquent. Kick ass yes, eloquent, no) where I can install all the crap I want and not have to worry about some bloated huge central depository of crap getting too big, or of the alternative, everything becoming so cross referenced and dependent that uninstalling anything becomes like a giant Jenga game.
Either pathway sucks.
DOS rocked, copied apps, ran apps, deleted apps. None of this installing or dependency bullshit.
Need help treating your acne? Come here!
Slightly offtopic:
It's really frustrating not to have a Linux kernel bug tracking system available. Searching through the huge lkml mailing list just doesn't cut it. And some questions pop back up every month, with no sign of it ever being addressed.
Example: the Athlon/VIA chipset freeze bug. Is it a chipset bug? A bios bug? A kernel bug? Is it fixed? Is it AMD's fault? Is it VIA's? Is it Linus's? Is it a PCI latency problem? An IDE problem?
Who the fuck knows!
There is a list of the new features in 2.5 here.
In summary:
Performance
- Major rewrite of the disk IO layer meaning better harddisk performance for Joe-user and high-end database servers as well
- New and faster scheduler
- Pre-empt scheduling for better interactive performance
Features- ALSA sound infrastructure
- Video for Linux redesign
- ACPI interface and other power-control patches. Especially a new software suspend-to-disk feature that does not involve Windows specific BIOS magic.
- Lots of high-end features (High memory, 64 bit processor support, per-CPU infrastructure, hot-swap CPU etc.etc.)
- JFS - Journaling filesystem from IBM (where's XFS?)
- Bluetooth
- USB-2.0
Security- Access Control Lists (ACL) which gives fine-grained security
- Per-process namespaces (some Al Viro hackery. Someone please tell that man to slow down a bit)
- Plugable quota system
And as usual a lot of new driver updates.Suspiciously missing are any memory management patches (although Rik has his reversed mapping patch in the pipe). Perhaps the topic is still a litte too hot...
The most important thing for me would be resource management features
I think that the with the current kernel you can already do much of this. But some of the new features of the 2.5 kernel allows for much more fine-grained control - like binding a process to a distinct CPU, better quota accounting etc. Perhaps thats what you're looking for ?
The direction of the 2.5 kernel seems to me to be mainly (but not exclusively) targetting enterprise systems.
Also, dammit, now you've got me wondering what the insult was in Monkey Island whose retort was something like 'get the POINT?'
Burning karma for Jesus.