[python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

[Brett Cannon]

On Wed, 30 May 2018 at 10:21 Donald Stufft <donald at stufft.io> wrote:

>
> On May 30, 2018, at 1:15 PM, Larry Hastings <larry at hastings.org> wrote:
>
> ISTM that opinions vary on what constitutes a "release blocker", and maybe
> empowering only the release managers to make that call would be a good way
> forward--which is what ISTM is what the Dev Guide already says anyway.  But
> I guess not!
>
>
> I think that RMs are empowered to decide what is a “real" release blocker,
> but you need some mechanism to flag an issue as potentially a release
> blocker for the RM to make a decision on it. Making a decision on that
> potentially release blocker should also itself be a release blocker
> (because if it’s possibly a release blocker, then we should treat it as
> such until the person empowered to make that call has decided one way or
> another).
>

And this is how I have always interpreted it. Larry is totally within his
rights to say "that is not a release blocker" and switch it to not being
one. At the end of the day it's Larry who presses the proverbial "Release"
button and that label technically means nothing if he chooses to ignore it.


>
> So I think for the system to work, you need to either allow anyone to flag
> an issue as a release blocker, and the RM is empowered to say “No this
> really isn’t” and unflag it, or you need two flags, for release blocker,
> and maybe release blocker, and both block the release.
>

Yep, or as MAL suggested, a "potential release blocker" or something where
we expect only RMs to push something all the way up to an actual "release
blocker".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/5e7b40ee/attachment.html>