Updated Schedule for F12

[Jesse Keating]

On Wed, 2009-07-08 at 17:00 -0700, John Poelstra wrote:
> o Added earlier blocker review days (f13)
> o Changed usage of "Release Candidate"  (f13)
> o Fixed dates for Beta phase so that "to" and "from" dates are
> correct 
> in the context of the report (notting)
> 
> http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html
> 
> Hopefully this version is a good starting point for the meeting f13
> said 
> he would arrange with QA at Monday's meeting.
> 

Hrm, something is still missing.  Here is the feedback that I gave
James.



Blocker Reviews) we need a blocker review day to happen with enough time
for maintainers to react and fix things prior to the freeze.  I see
there are ones scheduled for the 17th, 24th, and 31st, with the freeze
being Aug 4th.  This is good, but is there a good reason to have 3
before the freeze, rather than 2?  Just curious.  Also curious (and
forgetful) what the reason is we are doing these on Fridays.  What's
missing here is a review of the blocker bugs just before the RC compose
(is this implicit?) as well as one /after/ the RC compose and testing.


Test Composes) Releng would like to provide QA with at least one test
compose with enough time for QA to test and provide feedback prior to
the freeze.  This will help us and maintainers know what is broken and
needs fixing, saving nasty surprises and slips once we actually do
freeze.  On the current schedule I do not see any scheduled compose
prior to the freeze.  This means that the first time we'd have an
opportunity to test full media installs and reduced package sets, etc..
is after we've frozen and when we're under extreme time pressure to get
the release out.  High potential for slippage when operating this way.

Release Candidate)  Releng would like there to be only one scheduled
release candidate.  It is difficult to schedule because we cannot create
an RC until the blocker list is clear, see above needing a blocker list
review just prior to RC compose date.  Looking at Alpha, RC compose date
should probably be the 6th or 7th, to give QA enough time to test it and
to have a chance at second RC if necessary on the 10th or 11th.  To have
RC compose on the 6th, we'll need blocker review either on the 6th
morning, or 5th evening.  Either we're clear and can compose RC, or
we're not clear and we have to delay RC.  We'll need another blocker
review on the 10th evening or 11th morning.  Either we're clear and we
publish the previous RC, or there were new things picked up that need to
be fixed and we get another RC, or there are too many things to fix and
we slip.

I feel strongly that we shouldn't actually schedule a second RC.  That
just gives too much to the perception that things can wait until the
second RC to be fixed.  A second RC should be a disaster to be avoided,
not a constant to be assumed.  However I do think we should setup the
schedule to leave room for a second RC without a slip, should we need
it.

James, does this accurately describe what we discussed earlier?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20090710/4734fe51/attachment.sig>