Kernel bugs: out of control?

Posted May 11, 2006 15:03 UTC (Thu) by k8to (guest, #15413)
In reply to: Kernel bugs: out of control? by malor
Parent article: Kernel bugs: out of control?

I agree that the kernel development is being handled differently now,
which is resulting in a larger number of releases in the stable line. I
do not agree that this indicates a lower level of quality. I think it is
simply factual that the one does not necessarily imply the other.

Kernel releases with corrected functionality are being created faster
than in the past, enabling users to get these fixes sooner. If users
feel the need to reboot for every one of these updates, then the fixes
may be seen as something of a nuisance. However, the alternative is to
not apply the fixes. In the past, the choice was not available, fixes
were provided less frequently and less rapidly, and so there was a longer
window of vulnerability and no possibility for frequent reboots. You can
simulate the old situation by installing fewer kernels.

to post comments

Kernel bugs: out of control?

Posted May 13, 2006 20:19 UTC (Sat) by Baylink (guest, #755) [Link] (1 responses)

This sub-thread speaks to a topic near and dear to my heart: what does a version number *mean*?

Let me quote here my contribution to the Wikipedia page on the topic, based on my 20 years of observation of various software packages:

A different approach is to use the major and minor numbers, along with an alphanumeric string denoting the release type, i.e. 'alpha', 'beta' or 'release candidate'. A release train using this approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 == 1.0b1, 1.0b2 (with some fixes), 1.0b3 (with more fixes) == 1.0rc1 (which, if it's stable enough) == 1.0. If 1.0rc1 turns out to have bugs which must be fixed, it turns into 1.0rc2, and so on. The important characteristic of this approach is that the first version of a given level (beta, RC, production) must be identical to the last version of the release below it: you cannot make any changes at all from the last beta to the first RC, or from the last RC to production. If you do, you must roll out another release at that lower level.
The purpose of this is to permit users (or potential adopters) to evaluate how much real-world testing a given build of code has actually undergone. If changes are made between, say, 1.3rc4 and the production release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the real world, in fact contains changes which have not necessarily been tested in the real world at all.

The assertion here seems to be that an even higher level of overloading on version numbering ("even revision kernels are stable") and it's associated 'social contract' are no longer being upheld by the kernel development team.

If that's, in fact, a reasonable interpretation of what's going on, then indeed, it's probably not the best thing. I'm not close enough to kernel development to know the facts, but I do feel equipped to comment on the 'law'.

Kernel bugs: out of control?

Posted May 17, 2006 23:17 UTC (Wed) by k8to (guest, #15413) [Link]

I think your comments on versioning are not far from the mark. The fact
of these "minor" stable relases, eg. 2.6.X.Y, is that they are _smaller_
changes than have ever occurred in the stable series before. It is true
that these smaller changes do not receive widespread real-world
production evaluation, but no non-stable release kernel (rc versions
included) ever receives enough attention to catch even some showstopper
bugs.

So I think you are right to question this change, but the balancing facts
are that the release candidate process for the Linux kenel doesn't seem
very effective, and the changes made in the revision series are
_strongly_ conservative.

It is important to remember that in this particular (highly visible,
highly open) development process, there is very little pressure to
deviate from the conservative perspective in these updates.