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/
