Matthew Miller wrote:
Kevin, I'm missing something here. You're right that the QA
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
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
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
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.