On Fri, May 25, 2018, 07:53 Nick Coghlan, <ncogh...@gmail.com> wrote:
> 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). > That's how I've always done it as well. As Ned said, better safe than sorry by guessing at something being a release blocker than something accidentally being lost in the cracks. > 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/ >
_______________________________________________ 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/
