Larry Hastings larry at hastings.org
Wed May 30 15:07:41 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 11:59 AM, Brett Cannon wrote:
> On Wed, 30 May 2018 at 10:21 Donald Stufft <donald at stufft.io 
> <mailto:donald at stufft.io>> wrote:
>
>
>     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.
>
>
> Yep, or as MAL suggested, a "potential release blocker" or something 
> where we expect only RMs to push something all the way up to an actual 
> "release blocker".

I suggest we simply use the existing "critical" priority to also mean 
"potential release blocker".  If not, what would be the salient 
difference between a "critical" bug and a "potential release blocker" bug?


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/e62414b2/attachment-0001.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