Updated Schedule for F12

[Bill Nottingham]

James Laska (jlaska at redhat.com) said: 
> > > a little more I'm still not clear on our methodology.  We need a
> > few  
> > > specific dates that fit to get the time frame correct:
> > >
> > > 1) Date blocker list must be clear or slip the release
> > 
> > That's not a single date.
> 
> Sure, we have 2 in the schedule already.
> 
>       * 2009-10-19 - Create Test Compose (TC)
>       * 2009-10-26 - Compose RC
> 
> We miss either of those 2 dates ... it's time to do everyone a favor and
> start the exception process (aka slip).  We can wait until the point of
> no return when we sync to mirrors, but I think that does all those who
> plan to these dates a disservice.
> 
> There will be bugs surfacing, there always are ... it's software.
> However, we increased our chances this time by adding more bug days to
> ensure the bugs meet the established criteria and folks in QA have been
> improving documentation on how to characterize bugs (priority/severity
> and hopefully more release criteria soon).

Yes, but my understanding is that we want to start the RC process on
the 19th, and the test compose process *earlier*.

Let me try and rephrase what I thoght the process should be:

- At some earlier date (5th? 12th) we start regular test composes
  These test composes are like the 'snapshots' mentioned earlier,
  although hopefully more frequent, as we're more frozen and should
  have fewer issues.
- On the 19th, we start the RC composes, provided the blocker list
  is clear
- If the blocker list is not clear, we start making decisions as to
  whether to slip/no slip. But the composes are still made, and
  testing is still done. We may not slip even if the blocker list isn't
  clear on the RC start date of 10/19. An example:

  * Blocker list contains 20 items - start the slip process
  * Blocker list contains one item, consisting of "CD #6 too large",
    or "bash package not signed", etc. - don't start the slip process

  There's always going to be a little wiggle room.

- After all, we don't make a *final* slip/no-slip decision on the RC
  start day, as we do QA verification of the RCs, which can lead to a
  slip/no-slip decision.

- Therefore, a statement of 'date blocker list must be clear or slip
  the release' isn't meaningful, unless you mean the last drop-dead
  date of 10/29 or so. It (alas) can't be narrowed down to a final
  date.

Does that make more sense?

Bill