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
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
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.
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
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.