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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
