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

Comments

My guess

[commodoresloat]

is that you have way too much free time on your hands.

Re:My guess

[tanya2526]

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

Support the Protest Against Patents...

[Anonymous Coward]

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.

I would urge the /. staff to immediately shut down operations and support the
demonstration, unless they really don't care about open-source software at all.

May be a good businessmodel?

[Anonymous Coward]

Maybe a great open source businessmodel?

1) Do free stuff.
2) ?
3) Call your local bookeeper and gamble on kernel 2.6.0 release-date.
4) Profit!

My guess...

[FrostedWheat]

To quote a famous game developer: "When it's done."

Stable version?

[Vajsvarana]

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

Re:Stable version?

[Vajsvarana]

"Pretty stable" is one thing... by "Stable" I mean "No data corruption/work loss", which is another one.
Unfortunately 2.4.0 was "pretty stable" too, but until 2.4.18 reiserfs and block devices bugs caused many cases of data corruption, which costed to my firm quite a good amount of work and money.

Maybe I'm much too conservative on this, but I think that whichever software (expecially a kernel!) should not be considered "Stable" until the absence of crashes and data corruption has been thoroughly stress-tested. Sorry, but "it' been up for some days on some PC" is just not enough.

Flamebait? Maybe. But I really don't like the current attitude toward kernel versioning:

maybe it compiles -> devel
compiles (quite) and seems to work -> stable
no more serious bugs -> end of life, occasional maintanance

I think it shoud be:

maybe it compiles -> don't even release
seems to work -> unstable
no more serious bugs -> stable, thorough maintenance to squash last few bugs.

"End Of Life" of a stable version shoud happen only when a newer one goes stable. Waiting months to see the security breach on 2.4.20 corrected while no other stable kernel were around should happen NO MORE.

Forcing users to test new kernels by cheating on version numbers it's not a way to gain testers, but rather to loose many of them, after their data gets eaten...

Sure it compiles.

[noselasd]

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

November, 30th

[Crash42]

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.

Since when

[Bluelive]

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.

July 13

[muirhead]

Kernel 2.6.0-test1 was released by on July 13 2003.

What are you waiting for?

Should have been a poll

[G3ckoG33k]

This should have been a poll. Now, it just leads to endless ramblings.

LaLaLa

[NtwoO]

PROGRAMMERS DRINKING SONG:

99 little bugs in the code,
99 bugs in the code,
fix one bug, compile it again,
101 little bugs in the code.

101 little bugs in the code ...
(Repeat until BUGS = 0)

Re:LaLaLa

[IWannaBeAnAC]

(Repeat until BUGS = 0)

Which presumably happens when the bug count wraps around from 2^31 to -2^31+1 then up to zero...

Maybe this is the basis for Microsoft release schedules?

Wrong question

[GrouchoMarx]

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.

Re:Wrong question

[Karora]

What's important is when most distro companies (other than bleedinge edge Gentoo and "we don't need no steenking 2.x kernels" Debian)

Debian Unstable currently has 2.6.0-test kernels available.

Your complaint, which is perhaps mildly legitimate, is that Debian Woody (current "stable") was released with the standard default vanilla kernel as a 2.2 kernel.

In fact it had plenty of choices there for people who wanted to run 2.4 kernels - they just weren't the default standard vanilla choice.

Really: just what you want for a stable server-oriented environment.

Maybe

[thorgil]

Maybe I do... Oh wait... Yeah I do...

Re:beta testers

[jbert]

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