I talked to several people over the last couple days about what we can
do to try to avoid the "hero testing" treadmill that we've been on
during every Freeze in recent memory (specifically that we're usually
fixing Blocker bugs until the day before the Go/No-Go meeting and that
means that our QA team is pulling all-night test runs basically every
week).
I made the following suggestion to both Adam Williamson and David
Cantrell over the last couple of days and both seemed to think that this
is a reasonable approach (but for different reasons, interestingly).
Beginning with Alpha Freeze in Fedora 22, the policy would be amended to
include the following:
1. As currently, the Go/No-Go meeting must be held on the Thursday
preceding the planned Tuesday of public release.
2. At 1600 UTC on the Monday preceding Go/No-Go, a check of the known
Blocker list must be performed. If there are any blocker bugs that are
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*.
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
that week is canceled (or converted to a Blocker Bug review) and a slip
is *automatic*.
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
of the compose and the Go/No-Go meeting.
The idea here is to ensure that there is a clear engineering deadline in
order to guarantee that the QA team has a reasonable time period in
which to perform validation tests. I think this approach is too risky
this late in the F21 process, which is why I propose this only for
Fedora 22 and later.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
