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

[Ned Deily]

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 ;)

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
  nad at python.org -- []