2.6 and 2.7 Release Management 173
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."
A Good Thing... (Score:4, Interesting)
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
The backport concept (Score:2, Interesting)
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.
Don't forget the past (Score:3, Interesting)
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 :)
What are the proposed new features in 2.5 and 2.6 (Score:3, Interesting)
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
Simultaneous Release... (Score:3, Interesting)
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.
Slashdot (Score:3, Interesting)
To release or not to release (Score:3, Interesting)
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.
Even numbered releases HAVE to be stable! (Score:3, Interesting)
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...
Re:The backport concept (Score:2, Interesting)
First. The kernel is pretty damn stable. The instability people talk about are usually extreme cases or performance that is less than optimal. I have yet to see a 2.4.8 or later kernel lock up or panic on my typical hardware and I've got 3 machines running 24x7. I don't count the first 7 cuts becuase I was doing development on them and going to great pains to track them and they collectively should have been maybe to of the last 2.3.99 releases.
Linux is large. There are hundreds of regular contributors as well as a number of companies doing stuff. 2.3 lasted way to long and so everybody wanted to get their stuff in to 2.4 because 2.6 could be 2 years away after 2.4 came out. That was a mistake. The kernel underwent a lot of change during 2.3.99 and people were still adding tons of stuff. There were bitter fights about what should go in and when. You hate to be SGI, spend hundreds of thousands of dollars (I'm guessing that's the man hour cost) porting SGI and not make the cut and then wait 2 more years.
At the same time the releases need to be tempered. People say 2.0.40 is a bad sign because it needed 40 patches. We could be on kernel 4.2 now if we made the releases closer and that just creates more confusion in a lot of ways also. 2.4 took way too long and too much happened. 2.6 will be much better and the community needs to see that and get used to 6 to 9 to 18 months for a major release. Companies need to understand that and make their investments accordingly. It's difficult though because there are so many independant people developing stuff they are planning to get in and it all can't go to Linus when he says he's getting ready to lock it down.
I think if anything, maybe 2.7 should branch off before 2.6 is cut. Linux and the team and go through the big items and determine where and when and then make some timelines accordingly. You give people working on the bigger things a place to put their stuff. Then the final 2.5 releases shouldn't be as rushed.
Early unstable kernels are too broken anyway (Score:3, Interesting)
It's a catch-22 (Score:3, Interesting)
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.
My $0.02... (Score:4, Interesting)
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.
Either way is wrong (Score:2, Interesting)
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.
Re:Idea (Score:2, Interesting)
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.
How about they use some bug tracking system first (Score:5, Interesting)
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!