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

2018-05-30 Thread Ned Deily
On May 30, 2018, at 15:09, Donald Stufft wrote: > On May 30, 2018, at 3:03 PM, Larry Hastings 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

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

2018-05-30 Thread Donald Stufft
> On May 30, 2018, at 3:03 PM, Larry Hastings 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

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

2018-05-30 Thread Larry Hastings
On 05/30/2018 11:59 AM, Brett Cannon wrote: On Wed, 30 May 2018 at 10:21 Donald Stufft > 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”

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

2018-05-30 Thread Brett Cannon
On Wed, 30 May 2018 at 10:21 Donald Stufft wrote: > > On May 30, 2018, at 1:15 PM, Larry Hastings 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 wh

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

2018-05-30 Thread Larry Hastings
On 05/30/2018 10:21 AM, Donald Stufft wrote: On May 30, 2018, at 1:15 PM, Larry Hastings > 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

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

2018-05-30 Thread M.-A. Lemburg
In terms of process, it's always good to have a method to escalate a question to higher management in a way which doesn't require the manager to first parse long text messages. So a status such as "Potential Release Blocker" or "RM Review" sounds like a good way forward. Of course a friendly ping

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

2018-05-30 Thread Donald Stufft
> On May 30, 2018, at 1:15 PM, Larry Hastings 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 > gu

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

2018-05-30 Thread Larry Hastings
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 "rele

Re: [python-committers] Triage perms for Elvis

2018-05-30 Thread Andrew Svetlov
+1 On Wed, May 30, 2018 at 3:54 AM Lukasz Langa wrote: > +1 > > > On May 29, 2018, at 2:45 PM, R. David Murray > wrote: > > > > At Yuri's request I've given Elvis triage privileges on the tracker. > > I don't anticipate any objections, given the work he's done on > > What's New and other things