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

[Larry Hastings]

On 05/30/2018 10:21 AM, Donald Stufft wrote:
>
>> On May 30, 2018, at 1:15 PM, Larry Hastings <larry at hastings.org 
>> <mailto: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).
>
> 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.

Yes, ISTM that the Dev Guide covers this.  The section on priority says:

    Triagers may recommend this priority and should add the release
    manager to the nosy list.

In other words: if a dev thinks an issue should be a release blocker for 
version X, they should add the RM to the nosy list and make a comment 
recommending the issue be escalated to release blocker.  I thought it 
was telling that it /doesn't/ instruct triagers to mark the issue as a 
release blocker themselves.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/066e9d71/attachment.html>