Slashdot Mirror


Guessing Linux 2.6.0 Release Date

thorgil writes "Guessing about the linux-2.6.0 release date is hard, but here is a new angle (pseudo-scientific): I made a graph (gif) based on errors/warnings from John Cherry's (OSDL) compile statistics for linus' linux bitkeeper tree. My guess is around 12th October, 2003. What is your guess and more important, why?"

5 of 313 comments (clear)

  1. beta testers by btSeaPig · · Score: 2, Interesting

    For those of use that are running the 2.5/2.6beta kernel, what should we do when we do find bugs?

  2. Re:Sure it compiles. by leuk_he · · Score: 2, Interesting

    well looging at that dir:
    (and assuming morton will be the 2.6 maintainer)

    05/12/03 10:49PM 17,511 must-fix-1.txt
    05/12/03 10:50PM 19,024 must-fix-2.txt
    05/14/03 02:33AM 23,417 must-fix-3.txt
    05/15/03 12:38AM 27,594 must-fix-4.txt
    05/21/03 05:32PM 28,070 must-fix-4a.txt
    05/21/03 09:59PM 30,821 must-fix-5.txt
    05/30/03 11:35PM 15,294 must-fix-6.txt
    05/30/03 11:35PM 19,045 should-fix-6.txt

    The must fix list is not stable at all over time. It grew so big he made a split over must-fix and should-fix.

    and ther should be anology's between 2.4-test and 2.6-test

    Next bet: when will be 2.7 tree be opened?

  3. who checks in code that compiles with warnings? by Anonymous Coward · · Score: 1, Interesting

    seriously... that shit doesn't fly at most commercial software companies. why are people checking in code with compile warnings? why aren't they compiling the code and fixing the problems before checking in the code?

  4. The more interesting question is: by Advocadus+Diaboli · · Score: 2, Interesting
    How much will the release be delayed because of that f***ing SCO stuff?

    How much influence has SCO on the developers, e.g. make them response to the SCO FUD instead of fixing bugs in the kernel? That's also a sort of "denial of service" attack.

  5. Re:Wrong question by DrXym · · Score: 3, Interesting
    When the kernel itself is declared "released" is irrelevant to most people. If you really want the latest and greated, you can always download whatever the current version is, whatever it's called, and use it.


    Actually it's highly relevant. People (myself included to some extent) don't like running alpha/beta kernels on their everyday machines unless they have nothing of value if it all screws up. I'm sure I'll get the usual reassurances that -test1 "works fine for me" etc. but the point still stands.


    Now I think it's close enough to release that I'll give it a spin myself as it has some drivers I want, but then I'm capable of building and configuring the kernel. A vast number of people are not capable or inclined to do that and are waiting for their favourite dists to ship with it.


    Which comes to the second point. No distribution, be it Red Hat, Suse or even Mandrake is going to ship with a beta kernel by default. They're all waiting for 2.6.0 to be stamped and labelled, and possibly have a few more patches on top again before they'll bet the bank on it. Even if that means delaying their release, or having a 'backup plan' to ship a dual 2.4.x / 2.6.x system with support for the new kernel coming in the form of patches when it's ready. And believe me, 2.6.0 offers some extremely sexy stuff that dists and end users would dearly like, e.g. ALSA sound instead of the shitty OSS for one, but all kinds of improvements including general responsiveness tweaks. But only when its officially ready.


    So the new kernel getting to 2.6.0 (and deserving that moniker because it is now production quality) is extremely relevant to lots of people. That doesn't stop people from diving in when they feel comfortable, but the tidal wave is not going to happen until 2.6.0 goes final.