Re: RFD: Kernel release numbering

John Alvord
2005-03-05T10:14:01Z

On Thu, 03 Mar 2005 14:23:37 +0100, Rene Herman
<rene.herman@keyaccess.nl> wrote:

>Jeff Garzik wrote:
>
>> Rene Herman wrote:
>>
>>> Doing -pre and real -rc will get you more testers for -rc. Whether or
>>
>>> Add in the fourth level .k releases for real problematic bugs found
>>> after release as you did with 2.6.8.1, and I believe things should work.
>>
>> Precisely.
>
>I assume that one of the main problems with doing -pre is that actually
>doing a real -rc isn't much fun -- I can certainly understand that
>sitting around twiddling your thumbs by decree every few weeks is not a
>good model.
>
>You commented on the .k 4th level releases being an actual branch, BK
>wise. To not let the forced thumb-twiddling -rc period be a problem,
>this branch could happen at -rc1, after which Linus is again free to go
>merge up stuff into mainline for the next one, if he wants to.
>
>That's to say, I propose Linus doesn't change _anything_ other than
>renaming his -rc's -pre's, and his final -rc1 (well, and making it a
>branch if -final isn't a branch now, sorry, not a clue).
>
>The -rc branch then just sits there, and if nothing turns up that needs
>an -rc2, it gets released as final, and possibly onto .1, .2 and so on
>if useful or need be.
>
>Now, coaching that -rc branch from -rc1 through maybe -rcN to -final and
>possibly beyond may not be something Linus wants to do. The -rc branch
>would by definition see _no_ activity other than the really needed so I
>don't believe it would be much of a burden time-wise, but it is in fact
>not unlike what Alan is already doing with -ac. So, if Linus doesn't
>want that job, Alan may? Or someone else?
>
>Summarising:
>
>- Linus:
>
> 1) rename 2.6.N-rcX to 2.6.N-preX
> 2) when you'd now release, branch off, release as -rc1
> 3) go on with 2.6.(N+1)-pre1
>
>- Linus, Alan, or whoever else wants the job:
>
> 1) release -rc{2,3,...} only if needed.
> 2) release 2.6.N
> 3) do a 2.6.N.{1,2,...} only if needed.
>
>Is this sane? The advantage is, real -pre's and -rc's which will get
>more people onboard testing -rc, and hopefully without annoying Linus
>with real no-changing -rc's. How many more, enough or not, remains to be
> seen but certainly more.

One way to handle the transition into bug-fix only would be to turn
the tree over to the $stability crew at that moment. They would have
the job of nursing it to stability under the given ground rules.

john alvord