I think you're missing Arjan and Pekka's point: your proposal doesn'tYes, that's what I'm talking about. The change will be the "testX" thing. And as you already stated it will help more stable releases.
_really_ offer any change to the current procedure. It might make you
feel more warm and fuzzy but in practice:
1) Linus would still release a kernel (be it to -testX or "final")
when he and others feel it is time
2) The stable team will track fixes and release stable kernels as needed
The only thing that is different in your approach is the "final"
release would theoretically be more well tested. Unfortunately thatOf course as didn't embrace like the "rc" releases. I don't think that it will cause early stable fixes. Contrarily, it will produce more tested/stable releases. You may think it as a kind of "rc" series.
is not a valid assumption because the wider Linux audience likely
won't embrace the latest kernel until it is "final" anyway. This
delayed uptake can/will result in early stable fixes.
Again, no real change... we know that the "final" release that LinusIt is. As I described above : the "testX" series will change the things as producing more tested /stable releases. BTW, it should be much better to release less, trouble free kernels instead of releasing fast but fixing soon. Also, it will take the load of deep kernel testing. Linus should only do the applying the patches for the next kernel release via "rc" releases. Then when Linus decided all the patches, for the next kernel, applied he will pass it to the "testX" series maintainer as Chris did for 2.6.x.y.
makes _could_ have some minor oversight that will be fixed fairly
quickly by the stable team.