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

[Larry Hastings]

Well, I must admit, I'm a little baffled.  The text states unequivocally 
that the release manager is the only person who decides whether or not a 
bug is a "release blocker".  This means nobody else is permitted to make 
this decision.  So I don't see how somebody else can mark a bug as a 
"release blocker" without first deciding that it's a "release 
blocker"--which they're not permitted to do given the rules laid down by 
the Dev Guide.

But if that's not the intended Core Dev policy, then that's not the 
intended Core Dev policy.  Given that literally everybody else 
interpreted the text differently than me, this suggests that the text is 
at the very least ambiguous, if not outright misleading and should be 
updated.  I'll try to put together a PR to bring it more in line with 
everyone's de facto interpretation.

BTW, this all came up because a core dev marked a minor documentation 
change as a "release blocker" for the 3.5 branch, stating that they did 
this "because it'd be nice to see it make it out in the next release".  
ISTM that opinions vary on what constitutes a "release blocker", and 
maybe empowering only the release managers to make that call would be a 
good way forward--which is what ISTM is what the Dev Guide already says 
anyway.  But I guess not!


//arry/

On 05/25/2018 08:26 AM, Brett Cannon wrote:
>
>
> On Fri, May 25, 2018, 07:53 Nick Coghlan, <ncoghlan at gmail.com 
> <mailto:ncoghlan at gmail.com>> wrote:
>
>     On 25 May 2018 at 04:09, Ned Deily <nad at python.org
>     <mailto:nad at python.org>> wrote:
>
>         On May 24, 2018, at 13:46, Larry Hastings <larry at hastings.org
>         <mailto: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).
>
>
> 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   | ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>  
>     | Brisbane, Australia
>     _______________________________________________
>     python-committers mailing list
>     python-committers at python.org <mailto:python-committers at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/a15a3576/attachment.html>