On 25 May 2018 at 04:09, Ned Deily <n...@python.org> 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 ;) >
Right, my interpretation of that policy has been that to request RM review of a potential blocker I should: - set the status to Release Blocker - add the relevant RM to the nosy list - add a comment explaining why I think it might be a release blocker and asking the RM to take a look it at The RM then makes their decision by either commenting to say they're accepting the issue as a blocker, bumping it down to deferred blocker (if they don't think it's a blocker *yet*), or else bumping it down to one of the non-blocking priorities (if they don't agree that it's a blocker at all). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ 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/
