On Fri, Sep 13, 2019 at 5:54 AM Kamil Paral <kparal@xxxxxxxxxx> 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
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
