Date based [LWN.net]

Date based

Posted May 24, 2011 6:16 UTC (Tue) by corsac (subscriber, #49696)
In reply to: Date based by xxiao
Parent article: 2.8.0?

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

to post comments

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