Date based [LWN.net]

Date based

Posted May 25, 2011 0:40 UTC (Wed) by pflugstad (subscriber, #224)
In reply to: Date based by pflugstad
Parent article: 2.8.0?

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

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.