On 24.05.2018 20:09, Ned Deily wrote:
> On May 24, 2018, at 13:46, Larry Hastings <la...@hastings.org> wrote:
>> On 05/24/2018 10:08 AM, Ned Deily wrote:
>>> If you (or anyone else) feels strongly enough about it, you should re-open 
>>> the issue now and make it as a "release blocker" and we should discuss the 
>>> implications and possible plans of action in the issue.
>>
>> About that.  According to the Python Dev Guide:
>> Whether a bug is a *release blocker* for the current release schedule is 
>> decided by the release manager. Triagers may recommend this priority and 
>> should add the release manager to the nosy list.
>>
>> https://devguide.python.org/triaging/#priority
>> Of course, a particular release manager (e.g. Ned here) can change the 
>> policy for their releases.  But by default, unless you're the release 
>> manager for release X, you should not mark issues as "Release Blocker" for 
>> release X.  This seems like a sensible policy to me, and effective 
>> immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
> 
> I think we're reading the same words a bit differently.  There's no question 
> that the Release Manager makes the ultimate call whether an issue remains a 
> "Release Blocker" or not.  But it seems to me that the safest and most 
> reliable way to ensure that the Release Manager makes that decision is by 
> having a triager or submitter *provisionally* set the priority to "release 
> blocker".  It is then on the Release Manager's radar to accept or reject.  I 
> think that policy is totally in the spirit of the Dev Guide wording but I'm 
> fine with other release managers accepting differing interpretations for 
> their releases ;)
> 
> As for 3.6.x and 3.7.x, I would much prefer to have too many proposed 
> "release blocker" issues than to have too few.  And the sooner they are 
> reported, the better.

Ned's interpretation is the one I'm using for submitting such issues (maybe not
twelve hours before a final release). What other documented ways would you have
to get the attention of a release manager.

Having different interpretations depending on the release manager doesn't look
very practically.

Matthias
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Reply via email to