[python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

[Nick Coghlan]

On 25 May 2018 at 04:09, Ned Deily <nad at python.org> wrote:

> On May 24, 2018, at 13:46, Larry Hastings <larry at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180526/f137068b/attachment.html>