On Wed, Aug 14, 2019 at 11:26 AM Adam Williamson
If we say 3 days, then we're committing to doing all of that for a
blocker that's proposed the Sunday before the go/no-go - one day before
the final blocker review meeting. Which, I mean...yeah, we have time to
do all that. Juuust barely. :)
I dunno, it's hard to be sure what number is right exactly.
Consistent with the existing wording, any bug proposed during this
period has the smell of being "a last minute bug". It's a valid
position that consideration needs to save it from the policy, rather
than whether the policy applies. The category applies by virtue of the
bug being proposed during the period, there is a bias from the outset.
Ergo, in fact you have more bugs with this implicit bias with a 7 day
period, than a 3 day period. If it's a three day period, the last
Monday blocker means those blockers are blockers. That's rather last
minute, good chance they aren't getting fixed and we have to slip. If
this is 7 days, well only the really meaningful ones would cause a
slip, otherwise they are blockers for the next round.
In some ways this reminds me of printing newspapers. Those folks have
to print *another* paper tomorrow, so they can't fix all mistakes.
They simply run out of time, there really is a hard and fast deadline.
Every day. And I like anything that reduces the testing stress of the
final week to finding the really nasty bugs that we really shouldn't
ship with that can't easily be fixed with an update or just plain look
Another option here, is applying the last minute blocker to the
Release Target #1 week, and not to the Preferred Target week. Of even,
if it's a 3 day period apply it to the Preferred Target week; and if 7
days apply to Target #1 week.