On Sun, 2014-11-09 at 23:45 +0100, Kevin Kofler wrote: > 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. Apologies for the late response; I've been at a conference all last week. These new rules don't ban "preventing a slip", they attempt to eliminate the unreasonable demands we're putting on our volunteer QA team *every week during Freeze*. It's gotten out of hand and it's burning people out. The primary problem is that when we slip, there has never been a clear statement made about when exactly when the deadline is for devs to get their fixes in. Historically, devs have been operating under the assumption that as long as a package lands before the next Go/No-Go meeting, but that has failed to account for the time needed to create a new Test Compose (which takes approx. 8 hours right now) as well as time to have the QA team re-run the Release Validation tests (which takes an absolute minimum of 20 hours fueled by caffeine and adrenaline). This constant pause-then-panic situation is untenable and needs to be addressed. By instituting the above plan, we will be much more transparent about what the deadlines are for all participants (dev/maintainers, rel-eng and QA) and we relieve the latter two of some of their panicked efforts if we get to the Monday Blocker Review and it's clear that there is no realistic chance that the Thursday Go/No-Go will rule in favor. I considered making a modification to the slip-rule for the Monday blocker meeting that would allow us to *on rare occasions* add a single day to the devel cycle (if, for example, the last blocker fix is known and being prepared already), but I hesitated to include it in the policy for fear that it would be misused. Instead, perhaps we can just add the following line to the policy as written: "A one-time exception to the policy may be made if there is a unanimous agreement between the development (FESCo) representative, the rel-eng representative and the QA representative at the Monday Blocker Review meeting".
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
