Emacs solution [LWN.net]

Emacs solution

Posted May 24, 2011 0:00 UTC (Tue) by agrover (guest, #55381)
In reply to: Emacs solution by cesarb
Parent article: 2.8.0?

Or go all the way to Linux 3.0!

to post comments

Emacs solution

Posted May 24, 2011 2:16 UTC (Tue) by xxiao (guest, #9631) [Link] (35 responses)

Linux 2011.05

Year.Month can be used for good, no need to worry about 2.8, 3.0, 3.2, which is boring.

"What, why are you still using Linux 2004.06, that's too old, upgrade now!"
sounds better than
"Gosh, what is 2.6.7? when was it released?"

Date based

Posted May 24, 2011 3:43 UTC (Tue) by pflugstad (subscriber, #224) [Link] (31 responses)

I actually like this better than (essentially) the simply incrementing number used now. It gives you a much better feel for how old a particular kernel is.

Date based

Posted May 24, 2011 4:18 UTC (Tue) by neilbrown (subscriber, #359) [Link] (22 responses)

While I like date-based myself it has an awkward complication.

We don't know precisely when the next version of Linux will be released, so we don't know what it's name will be, so we cannot give meaningful names to the -rc releases that precede it.

I guess we could just decide that the next release will be 11.07 and if slips through to an August release date, we don't worry about it.
Or we could aim for early July, but call it 11.08.. then it is will probably be released early and we will look like we are very efficient.

Date based

Posted May 24, 2011 4:32 UTC (Tue) by xxiao (guest, #9631) [Link] (12 responses)

half-year based release seems predictable for other projects and a reasonable duration(close to the average gap between 2.6.x releases).

maybe it's time for Linus to stick to the 6-month release cycle now? this may bring efficiency for related projects as well, also you can have the long-term kernel every few years, this is how ubuntu works these days and it's quite good in practice I think.

Date based

Posted May 24, 2011 6:16 UTC (Tue) by corsac (subscriber, #49696) [Link] (11 responses)

> half-year based release seems predictable for other projects and a reasonable duration(close to the average gap between 2.6.x releases).

It's more like ~70 days, which is just above two months. Where do you pick that half a year from?

> maybe it's time for Linus to stick to the 6-month release cycle now? this may bring efficiency for related projects as well, also you can have the long-term kernel every few years, this is how ubuntu works these days and it's quite good in practice I think.

Well, ubuntu is fairly new in this game, but Gentoo was already using that release scheme (when they were still releasing). And that releasing scheme is not really a good indicator in case of a kernel. 2.6.32 has been released dec 3rd 2009 so it would have been called 2009.12 (or even 2009.9 if we count the merge window close) but latest release of that kernel was yesterday so it's not really a good indication of the level of support.

You can't say you have a two-years old kernel, you *must* upgrade, it's just wrong. All in all, I don't even think it's worth discussing that scheme, sorry for losing your time...

Date based

Posted May 24, 2011 6:29 UTC (Tue) by dlang (guest, #313) [Link] (10 responses)

if you think that the latest 2.6.32 really has all the fixes that are in 2.6.39 you are sadly mistaken.

yes, 2.6.39 contains some bugs that aren't in 2.6.32.x as well, and each organization should balance the risk of new bugs vs the risk of bugfixes not getting backported.

Date based

Posted May 24, 2011 6:31 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

if this is really a concern, then you could make the -stable version be the number of months between the kernel release and the -stable release (or if that's too complicated, make it year.month)

Date based

Posted May 24, 2011 6:34 UTC (Tue) by corsac (subscriber, #49696) [Link] (4 responses)

> if this is really a concern, then you could make the -stable version be the number of months between the kernel release and the -stable release (or if that's too complicated, make it year.month)

Sure, that's a lot easier than 3.0.42

Date based

Posted May 24, 2011 7:30 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

which is older, which is more 'stable'

3.0.42
3.9.3
3.10.0

2009.9.2.9/2009.9.33
2011.2.0.4/2011.2.4
2011.5.0

either way you do the date thing, you can then see how old the base kernel is, and figure out how recently it was updated (which also lets you notice when an old kernel series is no longer being updated)

Date based

Posted May 24, 2011 7:43 UTC (Tue) by corsac (subscriber, #49696) [Link] (2 responses)

> either way you do the date thing, you can then see how old the base kernel is, and figure out how recently it was updated (which also lets you notice when an old kernel series is no longer being updated)

My point is that we (usually) don't care how old the base kernel is for stable series.

Date based

Posted May 24, 2011 8:30 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

in my opinion you should care about how old the base of a kernel is.

there are a _lot_ of things that don't get backported, some is hardware support, some is performance improvements, some are cleanups of code that may or may not fix bugs, some are bugfixes that people don't think are important enough, some are bugfixes that are considered too intrusive/dangerous to backport.

the number of people working on doing backports is rather small compared to the number of people working on the latest versions

look at the number of patches in a -stable release, even the big ones are seldom more than 100-200 changesets, out of the 10,000 or so changesets in each new release. even if there are a LOT of -stable releases for a particular kernel, the number of changes that get backported are considerably less than 10% of the changes that go into the next release, and as a kernel gets older, fewer changes are backported. by the time you get to a kernel that's 10 releases back, I would guess that far fewer than 1% of the changes have been backported

actually, we can look at numbers for this (fun with git)

2.6.27 - 2.6.37 had 113521 changesets
2.6.27 - 2.6.27.57 had 2891 changesets

2.6.32 - 2.6.39 had 76108 changesets
2.6.32 - 2.6.32.27 had 2892 changesets

2.6.38 - 2.6.29 had 11031 changesets
2.6.38 - 2.6.38.7 had 3101 changesets

so I was a little off in my 1% guess, and I don't have the most recent versions of all the longterm kernels (I pulled from kernel.org and from the stable tree)

but do you really want to bet that the rest of the changes that did't get backported are really all for things you don't need?

Date based

Posted May 24, 2011 8:36 UTC (Tue) by corsac (subscriber, #49696) [Link]

> look at the number of patches in a -stable release, even the big ones are seldom more than 100-200 changesets, out of the 10,000 or so changesets in each new release.

This is more an advantage than a drawback.

> the number of people working on doing backports is rather small compared to the number of people working on the latest versions

Sure, but the changes are different too. And that's also why a lot of distributions use 2.6.32 for their stable, long time support release. So the stable maintenance work is shared.

> even if there are a LOT of -stable releases for a particular kernel, the number of changes that get backported are considerably less than 10% of the changes that go into the next release, and as a kernel gets older, fewer changes are backported. by the time you get to a kernel that's 10 releases back, I would guess that far fewer than 1% of the changes have been backported

That's the whole point of having stable releases.

> but do you really want to bet that the rest of the changes that did't get backported are really all for things you don't need?

Yes

Date based

Posted May 24, 2011 6:33 UTC (Tue) by corsac (subscriber, #49696) [Link] (3 responses)

> if you think that the latest 2.6.32 really has all the fixes that are in 2.6.39 you are sadly mistaken.

If you read again, you'll see I didn't say that.

> yes, 2.6.39 contains some bugs that aren't in 2.6.32.x as well, and each organization should balance the risk of new bugs vs the risk of bugfixes not getting backported.

2.6.39 (and all release since 2.6.33) are just that: new releases, with tons of new stuff added, stuff removed, lot of changes etc. 2.6.32 is *stable* release, which is something people really needed, especially at the kernel level. And it does get a lot of fixes, either directly or backported when needed.

On top of that, distributions do a good job filling the gap of the new hardware support by carefully backporting some drivers changes when needed.

Date based

Posted May 24, 2011 7:23 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

many fixes are backported, my point is that nobody tries to claim that all significant/important/needed/security/<your term here> fixes are backported

Date based

Posted May 24, 2011 7:42 UTC (Tue) by corsac (subscriber, #49696) [Link] (1 responses)

> many fixes are backported, my point is that nobody tries to claim that all significant/important/needed/security/<your term here> fixes are backported

I think you underestimate that amount, the amount of people working on that, the amount of time spent on that and the importance it has.

Date based

Posted May 24, 2011 11:15 UTC (Tue) by nicooo (guest, #69134) [Link]

> the amount of time spent on that

the amount of time wasted on that

ftfy

Date based

Posted May 24, 2011 5:08 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

name it based on when the merge window for that release opened. there's no ambiguity there.

Date based

Posted May 24, 2011 5:37 UTC (Tue) by kragil (guest, #34373) [Link] (4 responses)

While I think that most reasonable people would prefer a date based versioning scheme I think the marketing departments of all the big LF members would hate it.

Just imagine:
That brand new HP phone ships with Linux 2009.12?
Super awesome Enerprise Linux 15.6 Could Edition uses a patched 2005.1 kernel?

Date based

Posted May 24, 2011 5:57 UTC (Tue) by neilbrown (subscriber, #359) [Link] (2 responses)

> While I think that most reasonable people would prefer a date based versioning scheme

I would have thought so to, but at the kernel summit when Linus ran his "straw poll" (https://lwn.net/Articles/413061/) he didn't even ask for votes for that option as he assumed almost no-one would want it (and based on the votes he got for the other options, there is a fair chance he was right).

Date based

Posted May 24, 2011 6:19 UTC (Tue) by kragil (guest, #34373) [Link] (1 responses)

Hmm, that LWN article just states that kernel devs were against changing from 2.6 to something else. The way I read it it doesn't say that date based was less popular than anything else (besides staying with the current scheme)

Date based

Posted May 24, 2011 6:35 UTC (Tue) by neilbrown (subscriber, #359) [Link]

The article glosses over the boring details.

The way I remember it, there where 3 options:
A - no change
B - next version 3.0
C - change to date format.

Vote went:
A - 42
B - 33
C - let's not bother, no-one wants that.

Date based

Posted May 24, 2011 6:16 UTC (Tue) by dlang (guest, #313) [Link]

just imagine,

wouldn't that be nice?

Date based

Posted May 24, 2011 9:27 UTC (Tue) by epeeist (guest, #1743) [Link]

"We don't know precisely when the next version of Linux will be released, so we don't know what it's name will be, so we cannot give meaningful names to the -rc releases that precede it." So why not base the name on the month that it was started rather than the month that it was finished?

Date based

Posted May 26, 2011 17:27 UTC (Thu) by PaulDickson (subscriber, #478) [Link] (1 responses)

We code use [year].[release #] where year is determined by when the merge window opens and the release # is the number of releases for that year. This would mean we know in advance what the release would be when the merge window opens.

This would mean that we could have 2012.6 (or 12.6) released in 2013.

Date based

Posted May 30, 2011 20:28 UTC (Mon) by Max.Hyre (subscriber, #1054) [Link]

(or 12.6)

But what about the Y3k problem?

Date based

Posted May 24, 2011 6:59 UTC (Tue) by job (guest, #670) [Link] (2 responses)

How often do you actually want to know which year a kernel was released? I can't say I have ever done that.

It's mostly an excuse to have large version numbers, I think. What would be useful is information if a certain API is included, but that would not be very practical (imagine 2.6.nobkl.fuse.iwlwifi.etc...).

Date based

Posted May 24, 2011 7:22 UTC (Tue) by kragil (guest, #34373) [Link] (1 responses)

Well, first of all kernel releases are time based. So normal version numbers make less sense than date based ones. That just valid and logical.

Kernel devs may not need the dates, but it would help consumers comparing products that ship with Linux inside. Most grandmas won't care, but geeks and "prosumers" will.
And lazy companies couldn't BS people with stuff like: "We support the 2.6 kernel"

My hope is that a date based scheme would put a little more pressure on companies to work upstream and ship recent kernels.

But as I already said: Red Hat, HP, Google etc won't like it and they at the end of the day pay the bills for most of people deciding this, so it won't happen.

Date based

Posted May 24, 2011 10:38 UTC (Tue) by joib (subscriber, #8541) [Link]

Well, first of all kernel releases are time based. So normal version numbers make less sense than date based ones. That just valid and logical.

Well, if Linus goes ahead with 3.0 then it's a date based system, as Linus says himself. Namely 3.x is the x'th release in the 3rd decade since Linux was born. Perhaps Linus just doesn't want to base his versioning on the birth date of some religious figure.. :-/

Also, perhaps Linus shouldn't base his versioning on such provincial time units as various stuff related to how fast the earth rotates around its own axis and the suns. I vote for megaseconds (Ms) since the epoch!

As to the question whether some group will find the kernel version numbering scheme easy to understand, or acceptable, or whatever: Those for whom the kernel version matters can certainly figure out whatever scheme is used (as long as higher number == newer), for the rest it doesn't really matter (does your PHB know the version number of the Windows kernel in his laptop? No, I didn't think so either)

Date based

Posted May 25, 2011 0:40 UTC (Wed) by pflugstad (subscriber, #224) [Link] (3 responses)

Just to provide more detail on why I personally want this - we often have fights with management about sticking with some old crufty kernel, or going with a newer one. Simply saying: 2.6.27 is woefully out of date doesn't give the same sense as 2008.10 is almost 3 years old.

Yes I know all the other arguments about why you would want to use 2.6.27, but think about this: when 2.6.27 came out, a number of devices we use use frequently weren't even on the drawing board, or were brand spanking new and still being debugged (SSDs anyone?).

Date based

Posted May 25, 2011 17:37 UTC (Wed) by jzbiciak (guest, #5246) [Link]

Wow, you get to use 2.6.27? I'm still stuck with 2.6.9 on a (shudder) Pentium 4 at work.

Event based

Posted May 27, 2011 2:46 UTC (Fri) by jd (guest, #26381) [Link] (1 responses)

The reality is that kernel releases are event-driven, not time-driven. Which is good, as we'd have either thousands of brown-paper-bag releases or still be on version 1.x. Version dates are misleading, as the difference between two versions would yield no information on the number of events involved.

Now, one could argue that using events gives no indication of the time involved. However, when we talk of a kernel being "old" we don't been chronologically. What we mean is that the accumulation of time has resulted in a large enough change that the original is no longer tolerable.

It would, perhaps, be useful to increment by the number of significant kernel changes rather than by 1, at the cost of bloating the version number a bit. Gives more info, but only if there's a consensus on what is significant.

Chronological versioning, when the interval for a kernel is indeterminate (critical patches may come late and require several rounds of testing, for example, even for kernels with no user-significant changes), doesn't seem to tell you anything.

Event based

Posted May 27, 2011 3:20 UTC (Fri) by neilbrown (subscriber, #359) [Link]

> The reality is that kernel releases are event-driven, not time-driven.

On what evidence do you base that claim?

It hasn't always been this way but the current release process is very much time based. There is a 2 week merge window for bugs to be added (as well as new features), then a 2 month (approx) stabilisation period for most of those bugs to be removed (but no new features). Then Linus releases and we repeat.

Linus does have some discretion to adjust those times and to extend or shorten the stabilisation period as seems appropriate, so there is a small extent to which events do drive the release, but it is mostly time based.

Date based

Posted May 25, 2011 10:35 UTC (Wed) by danielos (guest, #6053) [Link]

Yes, but it says nothing about technology, or shouldn't be said nothing? It is a software component, it is not a distribution.
However there are so many technological change and improvements between version that i could not increase the more significative digit, and the least is too less...
In my opinion if Linus thinks that progressive change has lead to a technological gap that make, say, 2.6.12 a totally different thing than 2.6.40, and most developer (and user, say C developer) feel the same, it is ok to switch to 2.8.0
.. Maybe there is a bit of marketing, but it make sense

Emacs solution

Posted May 24, 2011 7:47 UTC (Tue) by cate (subscriber, #1359) [Link]

Let's update the kernel! Hmm. what patches I should download?

Now it is pretty simple, with a blind 'wget'.

And anyway the kernel version are also binary 8-bit coded, so numbers should be <255. I don't know if this could be patched (stable API).

Emacs solution

Posted May 25, 2011 15:18 UTC (Wed) by jonescb (guest, #74600) [Link] (1 responses)

In the LKML thread someone already mentioned that the version numbers have to fit into 8 bits which 2011 does not. They could use 11 like Ubuntu does, but that's going to be a problem in 2100 (Y2K all over again).

Emacs solution

Posted May 25, 2011 19:56 UTC (Wed) by dlang (guest, #313) [Link]

except for the fact that having version 100 be released in 2100 makes a lot more sense than 100 being the year 2000 did.

making the version be year-2000 will take us to 2255, which is long enough for that field to be expanded to more than 8 bits.

besides, don't you know that everything will be re-done by 2038 anyway when time_t runs out? that's the date to worry about, not 62 years later.