On Fri, May 25, 2018, 07:53 Nick Coghlan, <ncoghlan@gmail.com> wrote:
On 25 May 2018 at 04:09, Ned Deily <nad@python.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
On May 24, 2018, at 13:46, Larry Hastings <larry@hastings.org> wrote: 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@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/