On Thu, 2009-11-12 at 14:14 -0500, Bill Nottingham wrote:
1) Freeze
2) Are there blockers?
-> No!
-> Party!
-> make Alpha/Beta/Release candidate compose
-> test, etc.
-> Yes!
-> Bummer.
-> make a test compose
-> test, fix, etc.
-> goto 2)
A test compose only exists when we know we still have blockers to solve.
Otherwise it's an alpha/beta/release candidate. Therefore, we shouldn't be
adjusting the freeze schedule to add time for a 'test compose'.
We can certainly have additional test composes outside of the freeze for QE
to look at, but I don't know that they're events that affect the schedule
duration as much as they are simply point events in the schedule.
With exception to the final release, releng provided "Test Composes" to
QE before the scheduled freeze point. This was to allow QE to run
through the matrix with isos and see what might still be broken, so that
we could fix it /before/ we froze. It was an attempt to remedy the
situation where we freeze, then discover all the bugs, and subsequently
slip whatever release we froze for. This is what I want to see codified
on the schedule, the test compose before the freeze. We need to focus
more testing and effort /before/ the freezes as our freeze times are
really short and we inevitably slip them.
Making freezes longer isn't really a good solution, as that directly
prevents further development and cheats the later dates, however we
really need to look at this schedule in the viewpoint of no frozen
rawhide.
I owe a more through reading/reply to this schedule thread, I'm just
answering one part of it here.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca:
http://identi.ca/jkeating