Re: RFD: Kernel release numbering
From: Rene Herman (rene.herman_at_keyaccess.nl)
Date: 03/03/05
- Previous message: Adrian Bunk: "[2.6.11-rc5-mm1 patch] drivers/acpi/pcc_acpi.c: section fixes"
- In reply to: Jeff Garzik: "Re: RFD: Kernel release numbering"
- Next in thread: John Alvord: "Re: RFD: Kernel release numbering"
- Reply: John Alvord: "Re: RFD: Kernel release numbering"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 03 Mar 2005 14:23:37 +0100 To: Jeff Garzik <jgarzik@pobox.com>
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.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Adrian Bunk: "[2.6.11-rc5-mm1 patch] drivers/acpi/pcc_acpi.c: section fixes"
- In reply to: Jeff Garzik: "Re: RFD: Kernel release numbering"
- Next in thread: John Alvord: "Re: RFD: Kernel release numbering"
- Reply: John Alvord: "Re: RFD: Kernel release numbering"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
