Suggested Freeze Policy change for Fedora 22+

[Stephen Gallagher]

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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141117/67ee678d/attachment.sig>