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