Re: Linux 2.6.21

Daniel Barkalow
2007-04-26T06:52:52Z

On Thu, 26 Apr 2007, Adrian Bunk wrote:

> Number of different known regressions compared to 2.6.20 at the time
> of the 2.6.21 release:
> 14

I count 13. (v2) had 15 items, of which 2 were subsequently fixed or found
to be inapplicable.

> Number of different known regressions compared to 2.6.20 at the time
> of the 2.6.21 release with patches available at the time of the 2.6.21
> release [1]:
> 3

The -stable team can presumably take care of these in 2.6.21.1, right?
That leaves 10 that need developer attention.

John Stultz seems to be taking care of 3 of them.

Oliver Neukum has 1.

2 are particular drivers (ali_pata and rtl8139, according to the
reports).

2 seem to be ACPI-related; at least one has a candidate patch now.

1 seems to be an ALSA problem.

1 is STD and being debugged.

It looks like all of the known regressions are being worked on, and
getting fixes in for them is -stable material at this point. Furthermore,
it doesn't look to me like anyone who is needed for dealing with these
regressions is trying to get stuff into the 2.6.22 merge window.

I think it's clear that this is the right point for Linus to start the
2.6.22 cycle and leave the rest of the 2.6.21 work to the -stable team,
who are the experts of taking care of this sort of stuff. Furthermore, it
seems like -rc testers at this point have found everything in 2.6.21-rc
they're going to, so, again, it's time for new regressions. Personally, I'd
vote for having Linus leave off at 2.6.X-final, and have 2.6.X be the
first -stable release of the series, where the remaining known regressions
get fixed, but that's an issue of nomenclature, not development process.

I think you've allowed for a well-tested 2.6.21, and a good chance of a
2.6.21.1 or .2 with no known regressions against 2.6.20, which seems to me
like you succeeded as far as everything except making Linus a release
engineer.

-Daniel
*This .sig left intentionally blank*