Slashdot Mirror

← Back to Stories (view on slashdot.org)

2.6 and 2.7 Release Management

Posted by timothy on from the isn't-two-at-a-time-illegal dept.

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

15 of 173 comments (clear)

  1. A Good Thing... by phraktyl · · Score: 4, Interesting

    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)
  2. The backport concept by jhines · · Score: 2, Interesting

    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.

    1. Re:The backport concept by AxelTorvalds · · Score: 2, Interesting
      Backporting has been a stability problem and a source of great debate in the community.

      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.

  3. Don't forget the past by brunes69 · · 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 :)

  4. What are the proposed new features in 2.5 and 2.6 by Anonymous Coward · · Score: 3, Interesting

    The linux kernel,. besides stability .. what sort of things do they want top add/improve?

    better networking? better I/O performance?

    what about multiple CPU support?

    The most important thing for me would be resource management features .. 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?

    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

  5. Simultaneous Release... by Nighttime · · Score: 3, Interesting

    ...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.
  6. Slashdot by Catskul · · Score: 3, Interesting

    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
  7. To release or not to release by renehollan · · Score: 3, Interesting
    Look, no matter when you release 2.6, you will want to change it. So, if you never want to change it, you will never release it.

    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.
  8. Even numbered releases HAVE to be stable! by mojumbo · · Score: 3, Interesting

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

  9. Early unstable kernels are too broken anyway by iabervon · · Score: 3, Interesting

    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.

  10. It's a catch-22 by Chris+Pimlott · · Score: 3, Interesting

    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.

  11. My $0.02... by Zinho · · Score: 4, Interesting

    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
  12. Either way is wrong by IkeTo · · Score: 2, Interesting

    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.

  13. Re:Idea by Com2Kid · · Score: 2, Interesting

    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 :-)

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

    --
    Need help treating your acne? Come here!
  14. How about they use some bug tracking system first by Nicolas+MONNET · · Score: 5, Interesting

    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!