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, <ncogh...@gmail.com <mailto:ncogh...@gmail.com>> wrote:On 25 May 2018 at 04:09, Ned Deily <n...@python.org <mailto:n...@python.org>> wrote: On May 24, 2018, at 13:46, Larry Hastings <la...@hastings.org <mailto: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 <mailto:ncogh...@gmail.com>| Brisbane, Australia _______________________________________________ python-committers mailing list python-committers@python.org <mailto: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/
_______________________________________________ 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/
