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?"
It's ironic that slashdot would run a story about linux today at all. But what really surprises me is that Slashdot would continue operation today, even though they allegedly support the Online Demonstration Against Software Patents.
/. staff to immediately shut down operations and support the
I would urge the
demonstration, unless they really don't care about open-source software at all.
To quote a famous game developer: "When it's done."
The question that really count is when will the first stable version of 2.6.x be out. I mean 2.6.35 or such...
But I don't think the "it compiles, let's ship it" is the criteria for releasing 2.6.0 A better way is to look at Andrew Mortons must-fix list. When most items are fixes, it can be released. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/ must-fix/must-fix-6.txt
Should it be a linear best-fit? I'd be guessing that the number of errors/warnings will only approach zero? Much like tracking bugs.. On second thoughts, errors will more than likely hit zero but warnings we can live with.. :)
Anyway, interesting stuff
Oct, 12th is in about 6 weeks. So, because every IT project takes twice as long as you think, my guess is around Nov, 30th.
....Excuse me, but
Since when do compile time errors and warnings reaching zero mean that there no more bugs in a program? Most bugs are those the compiler doesnt complain about.
What are you waiting for?
This should have been a poll. Now, it just leads to endless ramblings.
Free time is what all of us visiting Slashdot have. And we like to play with our free time, or to find free time to play around with stuff to come up with something that excites us...
I think that gif is a nice hack. So lay off those "too much time on your hand" stuff..
however, I must ask myself - do hacks have to be necessarily of some utility? I mean, Zen would say "it will be out when it will be out".
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.
What's important is when most distro companies (other than bleedinge edge Gentoo and "we don't need no steenking 2.x kernels" Debian) will start building their distributions around 2.6-final instead of 2.4. For that, it's quite obvious at this point: The spring refresh cycle. (The fall cycle may have a few optional pre-release kernels, but the real action will be the spring.) Sometime in the April timeframe we'll see Red Had, Mandrake, and SuSE releasing 2.6-based versions. Hopefully they'll also have funness like KDE 3.2 and so on by then, which are just as important to most people.
When Linus says "ok, I'm done, let's work on something else" isn't important. When Red Hat says "we'll give you a support contract on this now", THAT'S important.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Do some searching around (linux-kernel mailing list archives, the bugzilla for linux-kernel) and try to work out whether it has already been reported.
Ensure that you can reproduce the problem on the latest kernel.
If the bug has only just appeared, it is very useful for the developers to know which kernel version it appeared in. The best way to find this out is to do a binary search between the working and non-working kernel versions.
If it has been reported, you might be able to contact the relevant maintainer (check the bug details or the MAINTAINERS file for details) and get a "possible fix" patch to try out.
If it hasn't been reported, I guess the best way to report it is to use the bugzilla. Please read and follow the advice there for how to report a bug, but again common sense applies.
Depending on the bug and your level of interest and ability, it can be really fun to try and work out a fix yourself.
(Sometime you can do this even if you aren't a great coder
e.g. Once I couldn't mount a CD and had a kernel message error about a 2k block size. I knew nothing about the driver, but grepped for the message, found it was bracketed by a "is it 1k or 4k" test. Simply adding 2k as another option to the "if" test and recompiling/rebooting allowed the CD to mount. That ruled.)
If you do produce your own fix, sending it to the relevant maintainer as a suggested change may be helpful, but please don't be upset if your fix isn't used. There are many reasons (some good, some bad) why something which works for someone isn't a good thing in general. (If you do send a patch, use 'diff -u oldfile.c newfile.c' to generate the patch file)).
Good luck
Hofstadters law:
"Everything takes longer than you expect, even when you take into account Hofstadters law."
Douglas Hofstadter, "Godel, Esher, Bach", ISBN: 0465026567
didn't Linus said that 2.6 was being released when x86 code was stable?
And other archs maybe would have to wait some minor versions?
Considering this and the graph predictions, my guess is 3-4th week of September.
I'm a chainsmokin' alcoholic sociopath, so-ci-o-path
I'm with you, though. I think Linux and its users would be much better off if the developers imposed a bit more process on themselves, and didn't rely so heavily on the "keep tweaking and releasing until it seems to be right" model.
... this reads like a troll, but... Eliminating warnings is often good, but sometimes will convolute code or make it less efficient. A good example is the seemingly endless type-casting circus my code ends up hosting. Regarding cooperations, it is a rare company that has effective coding standards that help and don't hurt productivity. Warning-free code should be a nice-to-have but never required. Otherwise you lose cycles to silly things when your next quarter is around the corner.
Sam
I'm going to guess it'll be delayed until the SCO code is publicly released so any problems can get cleaned up. Possibly in October we'll get a "gold level" release that would be the final kernal minus SCO fixes, that way if SCO loses it can just be rebranded without losing any worktime and if SCO wins the claim can always be made that as soon as the problem was shown it was fixed and never made it into the "final" kernal. Linus has been accused of being arrogant at times (mostly by folks with rejected code) but never accused of being stupid.
It doesn't matter what you wrap your emotions around, Reality is a brick wall specifically designed to scramble eggs
Slashdot is corporate-owned. It's a business. It makes money. They're not going to shut down their business for a day when they could be posting more SCO, "Microsoft hole," anime, and amateur rocket stories.
"Sufferin' succotash."