[python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
Larry Hastings
larry at hastings.org
Wed May 30 15:03:59 EDT 2018
More information about the python-committers mailing list
Wed May 30 15:03:59 EDT 2018
- Previous message (by thread): [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
- Next message (by thread): [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 05/30/2018 10:21 AM, Donald Stufft wrote: > >> On May 30, 2018, at 1:15 PM, Larry Hastings <larry at hastings.org >> <mailto:larry at hastings.org>> wrote: >> >> 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! > > I think that RMs are empowered to decide what is a “real" release > blocker, but you need some mechanism to flag an issue as potentially a > release blocker for the RM to make a decision on it. Making a decision > on that potentially release blocker should also itself be a release > blocker (because if it’s possibly a release blocker, then we should > treat it as such until the person empowered to make that call has > decided one way or another). > > So I think for the system to work, you need to either allow anyone to > flag an issue as a release blocker, and the RM is empowered to say “No > this really isn’t” and unflag it, or you need two flags, for release > blocker, and maybe release blocker, and both block the release. 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. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/066e9d71/attachment.html>
- Previous message (by thread): [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
- Next message (by thread): [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the python-committers mailing list