Kernel release status

[Posted February 17, 2010 by corbet]

The current development kernel is 2.6.33-rc8, released on February 12. Linus says:

I think this is going to be the last -rc of the series, so please do test it out. A number of regressions should be fixed, and while the regression list doesn't make me _happy_, we didn't have the kind of nasty things that went on before -rc7 and made me worried.

Full details can be found in the changelog.

According to the latest regression report, the number of unresolved regressions has risen to 31, the highest point yet in this development cycle.

Releasing with high number of regressions?

Posted Feb 18, 2010 4:11 UTC (Thu) by eparis123 (guest, #59739) [Link] (3 responses)

.. the number of unresolved regressions has risen to 31 ..

I'm no expert in managing huge projects, but I always wondered if releasing a project with big number of regressions, to meet a certain deadline, is the best approach possible. Can more experienced people comment on this?

Releasing with high number of regressions?

Posted Feb 18, 2010 9:03 UTC (Thu) by dlang (guest, #313) [Link]

the kernel isn't released to meet a deadline, it's released when Linus judges that the rate of fixes has dropped to the point of diminishing returns.

after some point, delaying the release doesn't make it much better, but makes the next release significantly worse. This is because people don't stop developing new stuff when a release is delayed, so there gets to be more and more new stuff in the next version.

as I see it, when several people start posting large patchsets for inclusion into the next kernel cycle it's about time to cut loose (unless there is a significant known problem)

this started happening about a week ago.

Releasing with high number of regressions?

Posted Feb 18, 2010 11:59 UTC (Thu) by njd27 (subscriber, #5770) [Link]

It's unlikely that this kernel will be released in distributions for another 6 months: I presume that we should expect any regressions to have been fixed in the stable series by then.

Releasing with high number of regressions?

Posted Feb 19, 2010 15:17 UTC (Fri) by iabervon (subscriber, #722) [Link]

Calling this particular transition "the release", as opposed to calling other versions that is a bit of an arbitrary decision. The direct effect of Linus doing this is that the change acceptance policy switches from the "late rc" rules to the "stable" rules. It makes a lot of sense to make this change with a certain number of regressions, because the "late rc" rules aren't really sufficiently tight to keep new regressions from arising. And Linus can't adopt "stable" rules for the mainline in the period shortly before the release, because the stable rules require changes to be in the mainline before they can be added to the stable branch.

There's also the fact that kernels don't get as much adoption (and therefore, as widespread testing) before whatever is marked as "the release" as they get after, which means that there's a point where most of the regressions in a kernel aren't being worked on because they haven't been discovered yet. There's little point in delaying a release until *all* of the regressions haven't been discovered yet. Also, when Linus does a release, it's a good time for developers of features which are taking several cycles to stabilize to merge mainline into their work (if that happens too frequently, their history gets messy and they start needing to include fixes for other people's bugs in order to keep working), which means that there's a segment of developers who only run a kernel derived from 2.6.x-rcN on the development systems when 2.6.x is released, which in turn means that producing a 2.6.x-rcN-derived kernel with few regressions depends on getting 2.6.x out first.

In general, you get good long-term quality and steady improvement by having a mainline frequently open for bleeding-edge development with a trailing edge that picks up regression fixes before it picks up new features.