On May 30, 2018, at 15:09, Donald Stufft <don...@stufft.io> wrote: > On May 30, 2018, at 3:03 PM, Larry Hastings <la...@hastings.org> wrote: >> Yes, ISTM that the Dev Guide covers this. The section on priority says: >> Triagers may recommend this priority and should add the release manager to >> the nosy list. >> In other words: if a dev thinks an issue should be a release blocker for >> version X, they should add the RM to the nosy list and make a comment >> recommending the issue be escalated to release blocker. I thought it was >> telling that it doesn't instruct triagers to mark the issue as a release >> blocker themselves. > > That seems a rather poor way of handling it TBH. A key thing is that an > escalation for a decision should itself be a release blocker, because if > someone thinks the issue might be, then we should get a decision on whether > it is or not before the release goes out. Relying on a comment seems far too > easy for the release manager to accidentally miss it or forget about it.
Yes. And I think Donald's earlier description of the current process was 100% correct. It is true that, at some level, the current "release blocker" could be broken into two separate states, a "release blocker proposed" and "release blocker accepted". But why? In nearly a dozen years of following the bug tracker and the Python process, I don't recall this ever coming up before. As a practical matter, there is absolutely no ambiguity as the issue history shows who set the priority to "release blocker". Again, it's a near foolproof way (since RM's are not allowed to make a release with a "release blocker" open against that release) to ensure the issue has been evaluated by the RM. And it has worked well for many people for many reasons. And it just doesn't happen very often, i.e. we don't have many release blockers. I think the only reason this came up was because of our policy, enforced by GitHub settings, that merges to "security fix only" branches may only be performed by the release manager, unlike other branches. And in this case, the core developer just wanted to make sure that the release manager saw and acted on the outstanding PR for the security branch. I think that action made perfect sense to me. So, I really really don't think there's a problem today that needs solving and, worse, the suggestions so far add complexity with no benefit at all as far as I can see. May I respectfully suggest that we just drop this discussion and move on, please? -- Ned Deily n...@python.org -- [] _______________________________________________ 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/
