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.
> >
> > --David
> > ___
> > python-committers mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
Thanks,
Andrew Svetlov
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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 
"release blocker" without first deciding that it's a "release 
blocker"--which they're not permitted to do given the rules laid down by 
the Dev Guide.


But if that's not the intended Core Dev policy, then that's not the 
intended Core Dev policy.  Given that literally everybody else 
interpreted the text differently than me, this suggests that the text is 
at the very least ambiguous, if not outright misleading and should be 
updated.  I'll try to put together a PR to bring it more in line with 
everyone's de facto interpretation.


BTW, this all came up because a core dev marked a minor documentation 
change as a "release blocker" for the 3.5 branch, stating that they did 
this "because it'd be nice to see it make it out in the next release".  
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!



//arry/

On 05/25/2018 08:26 AM, Brett Cannon wrote:



On Fri, May 25, 2018, 07:53 Nick Coghlan, > wrote:


On 25 May 2018 at 04:09, Ned Deily mailto:[email protected]>> wrote:

On May 24, 2018, at 13:46, Larry Hastings mailto:[email protected]>> wrote:
> On 05/24/2018 10:08 AM, Ned Deily wrote:
>> If you (or anyone else) feels strongly enough about it, you
should re-open the issue now and make it as a "release
blocker" and we should discuss the implications and possible
plans of action in the issue.
>
> About that.  According to the Python Dev Guide:
> Whether a bug is a *release blocker* for the current release
schedule is decided by the release manager. Triagers may
recommend this priority and should add the release manager to
the nosy list.
>
> https://devguide.python.org/triaging/#priority
> Of course, a particular release manager (e.g. Ned here) can
change the policy for their releases. But by default, unless
you're the release manager for release X, you should not mark
issues as "Release Blocker" for release X.  This seems like a
sensible policy to me, and effective immediately I'm going to
hold to this policy for my releases (3.4 and 3.5).

I think we're reading the same words a bit differently. 
There's no question that the Release Manager makes the
ultimate call whether an issue remains a "Release Blocker" or
not.  But it seems to me that the safest and most reliable way
to ensure that the Release Manager makes that decision is by
having a triager or submitter *provisionally* set the priority
to "release blocker".  It is then on the Release Manager's
radar to accept or reject.  I think that policy is totally in
the spirit of the Dev Guide wording but I'm fine with other
release managers accepting differing interpretations for their
releases ;)


Right, my interpretation of that policy has been that to request
RM review of a potential blocker I should:

- set the status to Release Blocker
- add the relevant RM to the nosy list
- add a comment explaining why I think it might be a release
blocker and asking the RM to take a look it at

The RM then makes their decision by either commenting to say
they're accepting the issue as a blocker, bumping it down to
deferred blocker (if they don't think it's a blocker *yet*), or
else bumping it down to one of the non-blocking priorities (if
they don't agree that it's a blocker at all).


That's how I've always done it as well. As Ned said, better safe than 
sorry by guessing at something being a release blocker than something 
accidentally being lost in the cracks.




Cheers,
Nick.

-- 
Nick Coghlan   | [email protected]   

| Brisbane, Australia
___
python-committers mailing list
[email protected] 
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/



___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of

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 
> 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.___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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 via some other channel usually
also helps get attention :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 30 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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 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/
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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 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).
>

And this is how I have always interpreted it. Larry is totally within his
rights to say "that is not a release blocker" and switch it to not being
one. At the end of the day it's Larry who presses the proverbial "Release"
button and that label technically means nothing if he chooses to ignore it.


>
> 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".
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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” 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/
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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 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.___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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 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
  [email protected] -- []

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/