Matthew Miller wrote:
Kevin, I'm missing something here. You're right that the QA
hero runs
are done to prevent slips, but I'm not seeing the logical connection
between what Stephen suggests and _banning_ them. The idea is to make
them less likely to be necessary with the cooparation of packagers as
we go up to the release.
Well, Stephen Gallagher wrote:
2. At 1600 UTC on the Monday preceding Go/No-Go, a check of the known
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
new strict deadline
Blocker list must be performed. If there are any blocker bugs that
are
^^^^
MUST
not marked as MODIFIED or ON_QA (meaning that they are filed as an
update in Bodhi), then the Go/No-Go meeting that week is canceled (or
converted to a Blocker Bug review) and a slip is *automatic*.
^^^^^^^^^^^^^^^^^^^^^
says it all
3. Relevant to the above, a Release Candidate compose must be started
^^^^
MUST
immediately after the above blocker review and must complete
successfully by 1300 UTC on Tuesday. Otherwise, the Go/No-Go meeting
^^^^^^^^^^^^^^^^^^^
another new strict deadline
that week is canceled (or converted to a Blocker Bug review) and
a slip is *automatic*.
^^^^^^^^^^^^^^^^^^^^^
says it all, again
4. If *new* blockers are discovered (or regressed) between the
Monday
blocker review and Thursday Go/No-Go, it is *permissible* for another
compose to be created if the following conditions are met:
a. The fix is capable of being produced and built quickly.
b. There is at least 24 hours remaining between the expected completion
^^^^^^^^^^^^^^^^^^^^^^^^^^^
yet another new strict deadline
of the compose and the Go/No-Go meeting.
So how do those new strict rules NOT ban preventing a slip? They spell out 3
strict deadlines which, if they are not met, AUTOMATICALLY trigger a slip.
Kevin Kofler