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 Deily n...@python.org -- [] _______________________________________________ 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/
