On Fri, Sep 13, 2019 at 5:54 AM Kamil Paral <kparal(a)redhat.com> wrote:
I'd like to revive this topic. Yesterday [1], the last minute blocker policy was
misused (at least in my eyes) to ignore the workstation oversize bug [2], which was
already accepted as an automatic blocker. I believe it was an inappropriate solution to
the situation, and last minute blocker policy directly contradicts automatic blocker
policy, i.e. they can't be used together, and the latter automatically beats the
former.
This is compelling. We don't even vote on automatic blockers. Anyone
can fill in the whiteboard.
As I feel it (and would like to have it), "automatic
blockers" imply they are such core and basic issues that they are non-questionable
and non-waivable (except by FESCo, which is itself part of the same policy and marked to
have godly powers). If you read the list of automatic blockers [3], those are broken
composes, dead-on-arrival images, incorrect checksums, broken dependencies, and *oversize
images*. I don't think anyone but FESCo should be able to say "go" in that
case, regardless of when the problem was reported (even minutes before the final meeting).
I'd really like automatic to mean automatic, without any consideration.
As a result, I propose that we add a note to the automatic blockers policy description
that sounds something like this:
"Automatic blockers can't un-accepted (waived), with the exception of
FESCo."
An alternative option would be to exclude just "last minute blocker bugs"
exception, but keep "difficult to fix" exception:
"Automatic blockers can't be subject to last minute blocker bugs exception
policy."
This would allow people in blocker review/Go-NoGo meeting to delay an automatic blocker
because it was difficult to fix, but would not allow them to delay it because it was
reported too late ("delay" here can mean from F31 to F32, not just Beta to
Final). For any other reason, the issue would have to be raised to FESCo.
I think the first proposal is better, but the second version works for me as well.
Anything that we don't deem "absolutely essential" should not be part of
the automatic blocker list. If we're OK with not keeping the maximum image size during
Beta, we should not have it there. The same applies to anything else in the list.
Don't misunderstand my email. I'm glad that F31 Beta is go. And I'm also not
sold on the idea of delaying Beta release because Workstation image is 50 MB over size.
But I believe we shouldn't sacrifice our policies consistency to achieve that goal.
That's why I want to clarify our policies. And then we can talk about dealing with
this particular situation in a better way (by excluding Beta image sizes from automatic
blockers, or perhaps keeping them just for release-blocking optical images, or bumping the
Workstation maximum size, improving our QA processes, etc).
I agree policies become diluted and vague, when they aren't followed.
If there's potential for judgement call, write in a tolerance. e.g.
Images can be up to 5% oversize for beta.
Otherwise, even hockey has more consistent rules with fewer
exceptions. And the decision really comes down to who makes the most
persuasive argument at that moment, rather than a set of policies that
provides the guidance.
--
Chris Murphy