Revamped Linux Kernel Numbering Concluded

kernel_dan writes "Following on the heels of a prior discussion about a kernel numbering scheme, KernelTrap has the conclusion. From summary: "Linus Torvalds decided against trying to add meaning to the odd/even least significant number. Instead, the new plan is to go from the current 2.6.x numbering to a finer-grained 2.6.x.y. Linus will continue to maintain only the 2.6.x releases, and the -rc releases in between. Others will add trivial patches to create the 2.6.x.y releases. Linus cautions that the task of maintaining a 2.6.x.y tree is not going to be enjoyable.'" Torvalds suggested specific guidelines to alleviate burn-out of the .y maintainer and Greg KH volunteered to begin maintainership."

Comments

Just one question:

[Anonymous Coward]

The *.x.y kernels are unstable.
The *.x only kernels are stable.

Won't there be a 28 day cycle for
stability on the *.x only kernel?

Burnout

[philovivero]

Torvalds suggested specific guidelines to alleviate burn-out of the .y maintainer

Did he say anything about the .NET maintainer? That'd take a serious toll on your sanity.

How *DO* you write a Linux device driver in C#?

Gregkh already made one point release

[Xpilot]

You can find it in his own subdirectory on kernel.org at:

http://www.kernel.org/pub/linux/kernel/people/greg kh/v2.6.11/

It includes tiny fixes such as a Dell laptop keyboard fix and a raid6 compilation fix for ppc.

Numbering... eek.

[Faust7]

Others will add trivial patches to create the 2.6.x.y releases. Linus cautions that the task of maintaining a 2.6.x.y tree is not going to be enjoyable.

2.6.x...
2.6.x.y...
2.6.x.y.z...

Kind of a Zeno's Paradox, isn't it?

Re:Numbering... eek.

[Anonymous Coward]

You're not seeing it - once they reach 2.6.x.y.z.z.y the solution to all the kernel's problems will appear.

Yes.

[ggvaidya]

And all bets are off if you try compiling more than one *.x.y kernel on the same computer ...

Here's an idea...

[rekoil]

Why not do 3.x, 4.x, ... like every other software developer in the world (well, except Microsoft and Apple...)?

Honestly, I don't understand the insistence on keeping everything at 2.x, 2.x.y, etc. If someone can explain the rationale to me, I'd be quite interested.

Re:Here's an idea...

[MarcQuadra]

Because bumps to the major version number indicate HUGE-scale rewrites, while the minor (.6 in this case) define feature-complete stable branches, and the trailing number at the end is for bugfixes and minor enhancements.

This is the way software SHOULD be versioned. It's the way Apple is versioning now, and it's the way Microsoft versions it's core systems (Windows XP SP2 = NT 5.1.2600).

Personally, I'd like for the odd-minor devel releases to go away and find some better way of versioning those, but everything else to-date has been sensible and sane, and I've been compiling my own kernels since the 2.1 series.

Re:Here's an idea...

[NitsujTPU]

Windows XP SP2 = NT 5.1.2600

Funny. Someone HAS to have planned that one.

Re:Here's an idea...

[MidnightBrewer]

I suspect the recent trend over the years to stay attached to point-point-point releases, especially for those projects that take forever and a day to hit 1.0, isn't so much an honesty thing as a sub-conscious desire to avoid responsibility for mistakes. I'm not referring to legal liability so much as professional pride. "Of course it has bugs, it's still not 1.0!" I'm sorry, but that's not realistic. People don't get paid to be perfectionists; that's a conceit to be enjoyed on your own time.

You do your best, you release it as 1.0, and then you start all over again to fix bugs and work towards the next full release. Making the numbers smaller doesn't change the quality of your software, it just helps a programmer live with the perceived embarrassment of not writing the perfect piece of code. In the final analysis, the numbers are all arbitrary; any sense of pride in your work or shame about your mistakes is a personal issue. Take Apple as an example. You could strip the 10 off of 10.3.8 and say that they are on version 3.8 of OS X. That means that version 4.0 is just around the corner, and that makes their turn-around cycle sound that much more impressive. To those who protest that a full point release demands unbelievable innovation and "drastic code re-writes," I have to ask, "Where is that written?" In the final analysis, versioning is all in your head. :)

Re:Here's an idea...

[Keeper]

The build numbers are based off of the number of months/days that have elapsed from build 0.

Re:Here's an idea...

[wiggles]

Apparently, you don't get it. See this.

Re:Here's an idea...

[Cthefuture]

It's not exactly the same. It's version 5.1 build 2600. A build number is a lot different than an actual version number.

Personally I think many projects (especially open-source) are getting out of hand with the version numbers. Just look at some of the version information on some Debian packages.

I mean, you have stuff like version "testing-4.3.0.dfsg.1-12.0.1". Does no one else see that as insane? I know each part has a purpose, but it seems more like improper project management. Is this possibly caused by a lack of proper scheduling? Things take too long and people start branching off into separate sub-versions.

It's the same thing with the kernel. I see no reason for official kernels to have so many frickin sub-versions. KISS, please. I think you reach a certain point and then the versions have lost all meaning. End-users can't keep track of all this stuff. Please implement better project management practices and just do actual releases with a simple versioning scheme.

What was wrong with the old way?

[AdamHaeder]

What was wrong with .4 being stable and .5 being test? Why not start a .7?

I haven't been following the kernel mailing list, but as a regular linux user from way back, I'm not clear on why the old way was dropped. This way seems a lot more confusing to me.

Re:What was wrong with the old way?

[A beautiful mind]

The developers just felt there is no urgent need for 2.7 yet and also that 2.6 can accept more features in a semi-stable state than it would be truly a need for 2.7.

Re:What was wrong with the old way?

[Atzanteol]

They're trying for a more rapid development cycle. 2.6 hasn't feature frozen like in the past.

It seems to be what the vendors want. RedHat 2.4 kernels have so much 2.6 stuff back-ported they're barely 2.4 anymore.

Re:What was wrong with the old way?

[Malor]

I've only ever had one comment modded down as Flamebait.... this may be #2.

As near as I can tell from reading recent comments on this particular decision, the single biggest reason they don't want to do 2.7 is because not enough people will test it. Only by calling it 'stable' can they get enough testers. Of course, the fact that it will now never really BE stable, seems to have been lost on them.

This is better than what they have been doing, but only slightly. What Linus seems to really want is for everyone in the whole world to be using the very most recent kernel. He wants, in essence, everyone in the world to be beta testers. By putting out new code and calling it 'stable', he gets hundreds of thousands of testers, and is able to shake out bugs much faster.

Apparently, the possibility that it might be banks and hospitals that are discovering these bugs didn't occur to them. Discovering a bug is an EXTREMELY PAINFUL PROCESS for someone who isn't expecting one. So instead of doing the nasty hard work of maintaining separate stable and development branches, they push that pain onto everyone else in the world.

Personally, I want software that works more than I want the latest whizbang feature. That's why I got onto Linux in the first place, a decade ago... I was frustrated with Windows. It was such a delight to run software that never, ever crashed. It was crude, it was simple, but it was *incredibly* reliable, and that more than any other single thing is why I switched.

I find it quite ironic that Windows 2003, in the hands of capable admins, with all its design flaws and warts, is substantially more stable than is Linux. There's a reason Ars Technica switched from Linux to Windows, and stayed there. If anyone on the planet is competent, it's those guys. And from the sound of it, they're very happy with the results.

At this point, I'm so disgusted with this state of affairs that I'm running a test installation of FreeBSD. Their development cycle is much saner. They don't have as many features, but the ones they DO have, seem to work. Maybe they should add a new motto: "Software by Adults, for Folks Who Could Lose Their Job if it Breaks".

*sigh*

Re:What was wrong with the old way?

[pikine]

Indeed, I feel that 2.6 was pushed out prematurely, but many features in it are desparately needed for publicity (for example, a working ACPI), so the kernel needs the "stable" status to give people incentive to use.

The fact that kernel developers are still adding new features suggest that it is still a development kernel. Stable kernels are for bug fixes. If they need new features to fix existing bugs, that's when they should bump up the stable version number.

However, I think version number is already obsolete for Linux kernels. We should be able to manage patchsets as if they're software packages, complete with dependency and conflict information that are automatically computed. When you want a "patch" to be included in your kernel, it looks for patches it depends on, checks to see whether it results in a conflict, and apply the patches. Periodically, "metapatches" are updated to depend on the most recent patches along some feature. More intricacies need to be worked out.

Assuming (0) that there is a demand for such a patch manager---I think the problem with developing it is that (1) it's difficult to develop a realistic test project from ground up using the patch manager, so the patch system can show that its design is useful, and (2) if we use an existing large software project (such as the Linux kernel), programmers for the patch manager would spend too much time following the development for that other project, rather than have useful work done; they might not want to do it. In general, we want to test the patch manager on a big project, but we also risk wasting too much time on the test project.

It would be best if the developers of a large project (can also think about the Linux kernel) will take the initiative into developing a patch manager, since they have a demand for it (or can be convinced to have a demand), already have a realistic software product, and are willing to follow the development of their own project.

I'm saying that there is a seed for an innovative patch management and revision control system from maintaining a Linux kernel. They should do something about it.

Re:What was wrong with the old way?

[Hackeron]

Arstechnica you say? -- isnt it ironic their site was down for atleast 5 hours about a week back?

Also, look at their uptimes on netcraft. There average uptime plummeted to about half since they switched to windows. Sure its still "good enough", but how can you possibly say 2003 is more stable that linux? - especially substantially more stable?

Re:What was wrong with the old way?

[moonbender]

There's a reason Ars Technica switched from Linux to Windows, and stayed there.

Yes, there is. Quoted from their article on the redesign:

Q. Why did you change over from Linux?

A. This is a loaded question, so we'll be brief. Ars started out on Windows NT back in 1998, but shortly after that we moved to FreeBSD, and then later, Linux. We ran Linux until March of 2004, when we made the move to Windows Servers. Linux and Apache had served us quite well, but when we turned to look at building our new CMS, .NET was simply so attractive for our needs that we felt it warranted the switch. If there are enough requests, we may do an article later documenting our thought process, but for now I'll say that the decision was largely a programming one, with the added benefit of the fact that more of us support Windows in our real lives than Linux.

I don't know - did they ever release that article documenting the thought process?

Re:What was wrong with the old way?

[legirons]

"There's a reason Ars Technica switched from Linux to Windows, and stayed there. If anyone on the planet is competent, it's those guys."

From the sounds of things, everyone competent there was utterly against the WindowsNT switch, which was introduced by management, caused horrible delays in shipping all their products, and caused most of the technical guys to leave.

But it sounded so much better as a soundbyte

I for one...

[pergamon]

...welcome our new many.version.levels.over.lor.ds.

This should help, if disciplined

[SpaceLifeForm]

The key is to make sure that the patches for the .y version are clean and really make sense from a stability standpoint *ONLY*. New functionality does not belong here.

Right now, I consider 2.6 not stable enough for my own use. If I cannot compile and boot a Linus kernel on a simple install of GNU/Linux (whether SuSE or Debian) without major headaches and/or chasing down patches, well, that's not stable enough for me. YMMV.

Back in 2.4, I wasn't really happy until 2.4.18, and with all of the changes in 2.6, I won't be surprised to see it meet my definition of stable until 2.6.20 at the current pace.

So, I'm hoping that this new approach will really help.

Re:This should help, if disciplined

[fishbowl]

"Are you running strange hardware or binary-only drivers or something?"

I have had severe problems with consoles on the Radeon framebuffer device (fixed since 2.6.10),
and also serious trouble with IDE CD writers (which is partly a kernel issue, partly client software).

In 2.6.11, I can get a CD writer to work if I put it as Master as /dev/hdc, on it's own ide bus with no hdd. The same configuration is never a problem under 2.4.

Other than these specific issues, 2.6 has not been a problem for me, but both these issues have been showstoppers. (The console on the framebuffer on a Radeon card is an absolute requirement of mine, as is CD writing to an ATAPI device.)

I wonder...

[Anonymous Cumshot]

If this will make Andres Salomon security & bug fixes patchset obsolete since it pretty much focuses on the same things that Linus wants to see for the 2.6.x.y releases..

FYI, Andres Salomon's patchset provides the foundation for Debian's kernels and has been discussed recently on kerneltrap here and here.

Why use x-y?

[J_Omega]

I'd have preferred r-theta polar coordinates.

Re:Why use x-y?

[J_Omega]

Depends on what you consider "natural" though, right? I'm willing to bet that the first human use of a coordinate system was polar. ie. "go 1000 paces, that-a-way"

Re:Why use x-y?

[MarkRose]

That, my friend, is a rad idea!

it wasn't until 2.6 ..

[Hohlraum]

that i regularly have seen breakages with stable hardware upon upgrading from one "stable" kernel release to the next. Granted most of them have been ACPI .. which is just a joke. All I gotta say in 2.7 please.

Re:Ummm

[Zorilla]

The preceding post has been brought to you by the Automated Joke Destroyer 5000.

Unavoidable

[Mark_MF-WN]

I think this is the unavoidable result of the Linux kernel's versatility. It's designed to be able to run on such a wide variety of hardware, from wee little embedded chips to multiprocessor monstrosities. It's able to run with some much old, obsolete hardware, cutting edge hardware, specialized hardware, etc. There's constantly new hardware coming out that needs to be supported, specific security requirements, etc. There's no way for the Kernel team to have it be everything to everyone at once. The natural result is the it's up to a distributor to put it all together, and choose appropriate combinations of patches.

There's nothing that wrong with depending on an organization (be it commercial like Mandrake or non-profit like Debian) to put together an appropriate Kernel for you. That's not to say you shouldn't give BSD a crack (diversity encourages vigour after all), but I don't think there's anything wrong with the way Kernel development is taking place. Those who needs a rock-solid unfliching kernel can always use a 2.4 series kernel, or use BSD (as you suggested).

Kernel enthusiasts

[Dragon Rojo]

I just have finished compiling this 2.6.11.0.0.0.0.1 kernel. Damn 2.6.11.0.0.0.0.2 is out, time to recompile.

Re:Kernel enthusiasts

[ThisIsFred]

Don't bother. All they fixed were some spelling errors in the comment lines.

You know

[mcc]

Linus Tourvalds keeps insisting he's just a coder and nothing more, and Alan Cox and everybody keep insisting he's just a coder and nothing more, but watching him in situations like this... he really is is disturbingly competent as a project manager. Like, to a degree that betrays a large amount of talent. I think he and others really sell him short... but of course one of the reasons he's so effective is because the relatively unassuming way in which he approaches things means people's attention is diverted elsewhere, thus allowing him to actually get stuff done :P

Re:release numbering ad absurdum

[koreaman]

Only when Donald Knuth takes over the Linux kernel...

BSD

[ari_j]

So you're saying that OpenBSD isn't dead, but that it will probably not procreate after it becomes legal for it to marry a same-sex operating system?

Re:Well, we appreciate it

[nate nice]

When you're getting paid a boatload to do it.

Confused?

[wiggles]

See this.