Plan for tomorrow's (20070604) Release Engineering meeting

[Thorsten Leemhuis]

On 03.06.2007 17:11, Jesse Keating wrote:
> On Sunday 03 June 2007 11:08:23 Jesse Keating wrote:
>> /topic RELENG-Meeting - Updates Policy - JesseKeating
>>
>> /topic RELENG-Meeting - Freeze Policy - JesseKeating
> 
> For these two topics I would really really like to get people to bring their 
> ideas and thoughts about this to our meeting.  Annoyances with the policies 
> used for Fedora 7, ideas on how to make it better, etc...  Come one, come 
> all.  I'll happily dedicate the entire meeting to these topics if need be.

Just a though: I was wondering if we should somehow split development
and release lines shortly before the release.

Rough Example: Ship test3; get the tree release-ready for two or three
weeks later. Create the release directories on the servers and issue a
RC from them with ISOs. Spread them; if important bugs are found: Fix
them in a rolling release scheme. One or two weeks later issue the real
release and freeze the repos; all updates from now on get into the
update repo.

Some of the Benefits:

- more testers might download the RC, as it will become the F7 final my
just running "yum update". They might find new bugs regular testers did
not hit

- rawhide development can start earlier again and is not blocked for
that long

Some of the Disadvantages:

- rawhide users don't test the final release. But at the point where we
split the tree should be in a proper shape already, so those that are
testing it for a long time already won't likely find new problems in any
care.

Risks:

- we need to be really strict and release a RC that is meant as a real
final and fix only important stuff afterwards that showed up in the RC
(e.g. something like the maxcpus=

As I said: Just a thought.

CU
thl