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

[Ned Deily]

On May 30, 2018, at 15:09, Donald Stufft <donald at stufft.io> wrote:
> On May 30, 2018, at 3:03 PM, Larry Hastings <larry at 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
  nad at python.org -- []