James Laska (jlaska@xxxxxxxxxx) 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
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
