From mariatta.wijaya at gmail.com  Fri Jun  1 19:07:32 2018
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Fri, 1 Jun 2018 16:07:32 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
Message-ID: <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>

Yup, the "mystery" was just for fun ?
There is no secret. I've been thinking that we should start using GitHub
issues instead of the b.p.o.

I realized not everyone was able to get to the language summit, and I fully
intended to update python-committers with this idea.
I just haven't been reading the mailing list for sometime until today.

For those who missed it, some resources:

1. My language summit slides (
https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-presentation
)
There are 3 bonus slides at the end which I did not get to cover, because
we were running late and it was lunchtime. (in the end, we were 3 hrs
overtime.)
Those can be discussed in core-workflow.

2. LWN article: https://lwn.net/Articles/754779/
I will not be reading/responding to the comments in LWN. ?

3. My initial research into this topic:
https://docs.google.com/document/d/1b3H-OQaZ7oc5jI9l7CEx9b_zCpao6PfEV1tIg0vpgG8/edit?usp=sharing


Mariatta

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180601/93639b84/attachment.html>

From antoine at python.org  Fri Jun  1 19:54:35 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 2 Jun 2018 01:54:35 +0200
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
Message-ID: <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>


Hi Mariatta,

Le 02/06/2018 ? 01:07, Mariatta Wijaya a ?crit?:
> 
> For those who missed it, some resources:
> 
> 1. My language summit slides
> (https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-presentation)
> There are 3 bonus slides at the end which I did not get to cover,
> because we were running late and it was lunchtime. (in the end, we were
> 3 hrs overtime.)
> Those can be discussed in core-workflow.
> 
> 2. LWN article: https://lwn.net/Articles/754779/?
> I will not be reading/responding to the comments in LWN. ?

Thanks for the pointers.

I agree with the UI concerns about b.p.o.  But I also agree with the
response mentioned in LWN.  Especially the lack of categorization in
Github issues.

I've used Github issues on other projects.  It's fine when you have a
small-to-medium number of open issues (say, no more than a couple
hundreds).  But I don't think it's usable for a project with several
thousands issues open.  At a micro level, the editing UI is pleasant to
use.  But at a more macro level, it's rather painful to navigate in a
large number of issues.

I wonder if other hosted services, such as Gitlab, offer a more
sophisticated issue tracker.

Regards

Antoine.

From barry at python.org  Fri Jun  1 20:29:57 2018
From: barry at python.org (Barry Warsaw)
Date: Fri, 1 Jun 2018 17:29:57 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
Message-ID: <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>

On Jun 1, 2018, at 16:54, Antoine Pitrou <antoine at python.org> wrote:
> 
> I wonder if other hosted services, such as Gitlab, offer a more
> sophisticated issue tracker.

Not really.  Mailman has a little less than 200 open issues, but they are basically categorized in the same way as GitHub, i.e. via labels.

https://gitlab.com/mailman/mailman/issues

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180601/c4233ee6/attachment.sig>

From levkivskyi at gmail.com  Fri Jun  1 20:59:23 2018
From: levkivskyi at gmail.com (Ivan Levkivskyi)
Date: Fri, 1 Jun 2018 20:59:23 -0400
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
Message-ID: <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>

On 1 June 2018 at 20:29, Barry Warsaw <barry at python.org> wrote:

> On Jun 1, 2018, at 16:54, Antoine Pitrou <antoine at python.org> wrote:
> >
> > I wonder if other hosted services, such as Gitlab, offer a more
> > sophisticated issue tracker.
>
>
Note that GitHub (and I think GitLab too) provides two additional ways to
categorise issues: project boards, and milestones.
I think together with labels this may simulate current b.p.o. structure to
certain extent. For example (approximately):
* We can have milestones for releases (including past releases)
* We can have "project boards" (slightly abusing this feature): new,
triaged, PR review
* Labels can be grouped using name prefix and color, for example (we have
similar structure in mypy):
  - priority-low
  - priority-normal
  - priority-etc...
  - kind-bug
  - kind-docs
  - kind-feature
  - topic-asincio
  - topic-etc..

This is still quite limited, but together with bots this can practically
replace current categorisation.

--
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180601/cc2ad735/attachment.html>

From tjreedy at udel.edu  Fri Jun  1 23:18:18 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 1 Jun 2018 23:18:18 -0400
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
Message-ID: <96b1f3ce-c1ef-094f-91a9-645e6a0bc430@udel.edu>

On 6/1/2018 7:07 PM, Mariatta Wijaya wrote:
> Yup, the "mystery" was just for fun ?
> There is no secret. I've been thinking that we should start using GitHub 
> issues instead of the b.p.o.
> 
> I realized not everyone was able to get to the language summit, and I 
> fully intended to update python-committers with this idea.
> I just haven't been reading the mailing list for sometime until today.
> 
> For those who missed it, some resources:
> 
> 1. My language summit slides 
> (https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-presentation)

"Old and languishing issues should just be closed / ignored"

I disagree with doing this blindly, and I would be mightily annoyed if 
someone did so with IDLE issues and hide valuable ideas and code.  For 
example:

In Sept 2006, Tal Einat suggested that IDLE's class browser, based on 
the pyclbr module, should report nested classed.
https://bugs.python.org/issue1612262

In August 2009, Guilherme Polo submitted patches for pyclbr and IDLE 
that also supported nested functions.  https://bugs.python.org/issue6691
I discovered the issue and approved of the idea in Sept 2015

In June and July 2017, Cheryl Sabella and I updated, rewrote, finished, 
and merged both patches.

To deal with issues better, we need

1. More core developers, so more modules can have maintainers.

2. Better support for core developers in the tracker.

2a. The ability to tag issues with the module (or perhaps modules) that 
an issue more pertains to.

2b. Associated (linked) manager or dashboard for issues pertaining to a 
module or group of modules.

There are currently about 60 idlelib module and 250 IDLE issues.  To not 
go crazy or become paralyzed, I keep a list (in a file) organized by 
topics, which mostly correspond to modules.  Since I started this, I 
have closed perhaps 40-50 issues.  For one thing, collecting together 
issues pertaining to a topic/module makes it easy to spot out of date 
and duplicate issues.

If I could tag IDLE issues with module names and retrieve them by 
module, that would partly duplicate what I have done.  It would also be 
nice to have the line online, and public, with issue numbers linking 
back to issues.  It would be nice if tagging an issue caused it to be 
automatically added to the appropriate sublist.

Would moving to github make such a substantial improvement?

> There are 3 bonus slides at the end which I did not get to cover, 
> because we were running late and it was lunchtime. (in the end, we were 
> 3 hrs overtime.)

Automerge: should signal separate from 'I approve of this PR'.  Commit 
message can be put in a labelled comment.  I have started editing the 
initial commit message.

tjr



From steve.dower at python.org  Sat Jun  2 10:30:24 2018
From: steve.dower at python.org (Steve Dower)
Date: Sat, 2 Jun 2018 07:30:24 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
Message-ID: <mailman.173.1527949832.2800.python-committers@python.org>

I think boards have improved since I last used them, but when I tried they added nothing but overhead. Possibly useful for planning, if we had someone who was responsible for that (maybe individual planning? But then you can?t really expect contributors to keep it up to date for you).

Milestones are one-per-issue, and get rolled up in a way that is most useful for planning rather than search or review. I use these all the time on work projects.

A good set of tags (which unfortunately are shared with the set of tags you can put on a PR) and some automation to auto-subscribe the core devs associated with that tag is a bare minimum, as far as I?m concerned. It would be nice if issue search supported the OR operator as well, but it can only do AND.

I?m far from convinced that GitHub issues will work well for an active team as large as ours with as little coordination as we use. It doesn?t work well for the ?bucket of bugs? I keep open on one of my work projects, even though the team is smaller, and our tracker is almost entirely a bucket of bugs.

Top-posted from my Windows 10 phone

From: Ivan Levkivskyi
Sent: Friday, June 1, 2018 18:05
To: Barry Warsaw
Cc: python-committers
Subject: Re: [python-committers] Comments on moving issues to GitHub

On 1 June 2018 at 20:29, Barry Warsaw <barry at python.org> wrote:
On Jun 1, 2018, at 16:54, Antoine Pitrou <antoine at python.org> wrote:
> 
> I wonder if other hosted services, such as Gitlab, offer a more
> sophisticated issue tracker.

Note that GitHub (and I think GitLab too) provides two additional ways to categorise issues: project boards, and milestones.
I think together with labels this may simulate current b.p.o. structure to certain extent. For example (approximately):
* We can have milestones for releases (including past releases)
* We can have "project boards" (slightly abusing this feature): new, triaged, PR review
* Labels can be grouped using name prefix and color, for example (we have similar structure in mypy):
? - priority-low
? - priority-normal
? - priority-etc...
? - kind-bug
? - kind-docs
? - kind-feature
? - topic-asincio
? - topic-etc..

This is still quite limited, but together with bots this can practically replace current categorisation.

--
Ivan




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180602/8813f4e5/attachment.html>

From mariatta.wijaya at gmail.com  Sat Jun  2 15:46:39 2018
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Sat, 2 Jun 2018 12:46:39 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <40ykBg6d1DzFqpT@mail.python.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
Message-ID: <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>

>
> "Old and languishing issues should just be closed / ignored"
> I disagree with doing this blindly, and I would be mightily annoyed if
> someone did so with IDLE issues and hide valuable ideas and code.


Since you are IDLE's maintainer, I'll also be annoyed if other people
except yourself (or other IDLE maintainers) blindly close IDLE issues
without consulting you.

Many modules don't have maintainers anymore. If such issues have been
ignored for all these years, we'll probably never get to it. Might as well
close it.

The proposed idea is to provide a button that can copy over conversations
from a b.p.o issue to GitHub, and to continue discussions in GitHub. If
core devs have a list of issues they still care about, then they use this
not yet existing magic button.

The closed issue will still be in bpo, and anyone motivated enough can
migrate it to GitHub.

To deal with issues better, we need
> 1. More core developers, so more modules can have maintainers.


We need more core developers anyway, regardless of what tracker we're
using. That is a separate problem.

And perhaps this is to be discussed in a separate thread: even though in
the b.p.o we appear to have 170 committers, really there are 90 core devs
(people who has commit right to CPython on GitHub). and out of those 90, I
think only about half are currently active (since the migration to GitHub).
So yes, we need more (active) core devs.

2. Better support for core developers in the tracker.


Not sure what you mean by "support"? There are only two maintainers of the
bug tracker, they both are also Python core developers: Brett and Ezio. My
personal opinion is: they're more valuable elsewhere instead of supporting
the bug tracker. At its current state, the bug tracker is not ready to take
up new contributors, and it will not be easy effort to onboard new bpo
maintainers.

2b. Associated (linked) manager or dashboard for issues pertaining to a
> module or group of modules.


We can try the project boards as Ivan mentioned? https://help.github.com/
articles/about-project-boards/

* Labels can be grouped using name prefix and color, for example (we have
> similar structure in mypy):
>   - priority-low
>   - priority-normal
>   - priority-etc...
>   - kind-bug
>   - kind-docs
>   - kind-feature
>   - topic-asincio
>   - topic-etc..


I kinda like those!

I wonder if other hosted services, such as Gitlab, offer a more
> sophisticated issue tracker.


One thing I'm trying to avoid is having separate issue tracker and repo,
and needing different accounts.

Possibly useful for planning, if we had someone who was responsible for that
>


Perhaps for a project the size of Python we should have a dedicated Project
manager.


Mariatta
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180602/1fd2f1b2/attachment.html>

From brett at python.org  Sat Jun  2 16:26:42 2018
From: brett at python.org (Brett Cannon)
Date: Sat, 2 Jun 2018 13:26:42 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
Message-ID: <CAP1=2W4oRZ87ZfN35NuxRygaL8=C85hbuK2PyaVWp++yF2ox6g@mail.gmail.com>

On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya <mariatta.wijaya at gmail.com>
wrote:

> [SNIP]
>
> 2. Better support for core developers in the tracker.
>
>
> Not sure what you mean by "support"? There are only two maintainers of the
> bug tracker, they both are also Python core developers: Brett and Ezio. My
> personal opinion is: they're more valuable elsewhere instead of supporting
> the bug tracker. At its current state, the bug tracker is not ready to take
> up new contributors, and it will not be easy effort to onboard new bpo
> maintainers.
>

I actually wouldn't list me as a maintainer of b.p.o. I only have passing
knowledge of the code due to reviewing Ezio's changes to support the CLA
bot. It used to be RDM, Ezio, and Maciej, then DRM got busy, and then
Maciej got busy with helping move our hosting over to OpenShift and off of
our previously free hosting provider who sold their business (I also think
Maciej is also busy with other things). I don't know what Ezio's
availability currently sits at, but I have not heard from him recently.

If you look at
https://hg.python.org/tracker/roundup/shortlog/bugs.python.org there has
not been an update to the repo's code in 8 months but there have been
reported issues as recently as yesterday:
http://psf.upfronthosting.co.za/roundup/meta/ .

IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF
infrastructure team can re-start the instance if it falls over, but no one
is working on e.g. fixing log-in issues or any of the various UX issues we
are all painfully aware that b.p.o has.

As I said at the language summit, if people want to keep b.p.o around then
we need to get some volunteers to staff it. I personally would like to see
three people step forward and say they will work to improve b.p.o to make
sure it functions as expected now and plan to improve it long-term. But I
personally would settle for just two people actively working towards making
b.p.o a tenable solution (the three person goal is just from experience of
always wanting at least one backup even if someone goes on vacation or does
an OSS detox).

But as of right now we have zero people supporting b.p.o (and GitHub has
one with Mariatta which puts GH ahead in my book). Because of this, in my
opinion this discussion shouldn't include b.p.o as an option until those
volunteers materialize. We can argue GitHub versus GitLab versus some other
issue tracker (open or closed source, self-hosted or service-hosted I
personally don't care; heck write it from scratch like Warehouse if that's
what it takes), but unless we get some people to step forward to help with
b.p.o then I personally consider it our temporary solution until we figure
out where we're going next with b.p.o and not a viable option in this
discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180602/9728cf01/attachment-0001.html>

From willingc at gmail.com  Sat Jun  2 17:55:28 2018
From: willingc at gmail.com (Carol Willing)
Date: Sat, 2 Jun 2018 14:55:28 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAP1=2W4oRZ87ZfN35NuxRygaL8=C85hbuK2PyaVWp++yF2ox6g@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <CAP1=2W4oRZ87ZfN35NuxRygaL8=C85hbuK2PyaVWp++yF2ox6g@mail.gmail.com>
Message-ID: <3727641C-C637-4C0F-90DB-25FE0ADF388D@gmail.com>

Would it be possible to get a database(s) download of all of the b.p.o. data (redacting privacy information if needed)?

I would like to work on a proof of concept using the scientific python stack, particularly Pandas, to see if we can do a GitHub/GitLab (pick your favorite) for all new issues and a front end (Flask, Django, Pyramid, etc.) for historical data. This would be much easier to do with access to the underlying data.



> On Jun 2, 2018, at 1:26 PM, Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> 
> 
> 
> On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya <mariatta.wijaya at gmail.com <mailto:mariatta.wijaya at gmail.com>> wrote:
> [SNIP]
> 
> 2. Better support for core developers in the tracker.
> 
> Not sure what you mean by "support"? There are only two maintainers of the bug tracker, they both are also Python core developers: Brett and Ezio. My personal opinion is: they're more valuable elsewhere instead of supporting the bug tracker. At its current state, the bug tracker is not ready to take up new contributors, and it will not be easy effort to onboard new bpo maintainers.
> 
> I actually wouldn't list me as a maintainer of b.p.o. I only have passing knowledge of the code due to reviewing Ezio's changes to support the CLA bot. It used to be RDM, Ezio, and Maciej, then DRM got busy, and then Maciej got busy with helping move our hosting over to OpenShift and off of our previously free hosting provider who sold their business (I also think Maciej is also busy with other things). I don't know what Ezio's availability currently sits at, but I have not heard from him recently.
> 
> If you look at https://hg.python.org/tracker/roundup/shortlog/bugs.python.org <https://hg.python.org/tracker/roundup/shortlog/bugs.python.org> there has not been an update to the repo's code in 8 months but there have been reported issues as recently as yesterday: http://psf.upfronthosting.co.za/roundup/meta/ <http://psf.upfronthosting.co.za/roundup/meta/> .
> 
> IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF infrastructure team can re-start the instance if it falls over, but no one is working on e.g. fixing log-in issues or any of the various UX issues we are all painfully aware that b.p.o has.
> 
> As I said at the language summit, if people want to keep b.p.o around then we need to get some volunteers to staff it. I personally would like to see three people step forward and say they will work to improve b.p.o to make sure it functions as expected now and plan to improve it long-term. But I personally would settle for just two people actively working towards making b.p.o a tenable solution (the three person goal is just from experience of always wanting at least one backup even if someone goes on vacation or does an OSS detox).
> 
> But as of right now we have zero people supporting b.p.o (and GitHub has one with Mariatta which puts GH ahead in my book). Because of this, in my opinion this discussion shouldn't include b.p.o as an option until those volunteers materialize. We can argue GitHub versus GitLab versus some other issue tracker (open or closed source, self-hosted or service-hosted I personally don't care; heck write it from scratch like Warehouse if that's what it takes), but unless we get some people to step forward to help with b.p.o then I personally consider it our temporary solution until we figure out where we're going next with b.p.o and not a viable option in this discussion.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180602/d79e3a62/attachment.html>

From ezio.melotti at gmail.com  Sat Jun  2 17:57:55 2018
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 2 Jun 2018 23:57:55 +0200
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAP1=2W4oRZ87ZfN35NuxRygaL8=C85hbuK2PyaVWp++yF2ox6g@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <CAP1=2W4oRZ87ZfN35NuxRygaL8=C85hbuK2PyaVWp++yF2ox6g@mail.gmail.com>
Message-ID: <CACBhJdHBysO2LwdyHvjCUw7=6aZb_F8mXLB2paYVUmAVmm5-6Q@mail.gmail.com>

Hi,

On Sat, Jun 2, 2018 at 10:26 PM, Brett Cannon <brett at python.org> wrote:
>
>
> On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya <mariatta.wijaya at gmail.com>
> wrote:
>>
>> [SNIP]
>>
>>> 2. Better support for core developers in the tracker.
>>
>>
>> Not sure what you mean by "support"? There are only two maintainers of the
>> bug tracker, they both are also Python core developers: Brett and Ezio. My
>> personal opinion is: they're more valuable elsewhere instead of supporting
>> the bug tracker. At its current state, the bug tracker is not ready to take
>> up new contributors, and it will not be easy effort to onboard new bpo
>> maintainers.
>
>
> I actually wouldn't list me as a maintainer of b.p.o. I only have passing
> knowledge of the code due to reviewing Ezio's changes to support the CLA
> bot. It used to be RDM, Ezio, and Maciej, then DRM got busy, and then Maciej
> got busy with helping move our hosting over to OpenShift and off of our
> previously free hosting provider who sold their business (I also think
> Maciej is also busy with other things). I don't know what Ezio's
> availability currently sits at, but I have not heard from him recently.
>

I haven't actively worked on the tracker, but I kept an eye on it and
acting when needed (e.g. yesterday I deployed a fix committed by
Berker :).
If needed I can pick it up again.
It should also be mentioned that before us, MvL also used to work on
the tracker, and he added the Rietveld and openid integration (and
these parts are not very well maintained now).

> If you look at
> https://hg.python.org/tracker/roundup/shortlog/bugs.python.org there has not
> been an update to the repo's code in 8 months but there have been reported
> issues as recently as yesterday:
> http://psf.upfronthosting.co.za/roundup/meta/ .
>

This is a bit misleading:
* that repo is updated only when Roundup is updated otherwise it sits
there waiting for a new release. Roundup 1.6 is going to be released
soon;
* the repo for our instance is
https://hg.python.org/tracker/python-dev/shortlog/default .  This also
didn't get many commits lately, however
* the meta tracker also didn't get many new issues.  Only 7 issues in
the metatracker have had any activity in the last 3 months, 2 are
about SSL failure/certificates, 3 are about email ending up in the
spam, one is about Google auth (however I'm not familiar with that
part of the code), and the last one is a minor issue with a simple fix
that needs to be tested/deployed.

IOW there aren't many commits because there aren't that many issues
with the code and because Roundup 1.6 hasn't been released yet.


As mentioned above, the Roundup team is about to release Roundup 1.6.
This release drops support for Python <2.7.
AFAIU the infra team wanted to move/upgrade the machine running b.p.o
(that is currently still running Python 2.6).  When that happens (and
once Roundup 1.6 is released) we will upgrade it.


> IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF
> infrastructure team can re-start the instance if it falls over, but no one
> is working on e.g. fixing log-in issues or any of the various UX issues we
> are all painfully aware that b.p.o has.
>
> As I said at the language summit, if people want to keep b.p.o around then
> we need to get some volunteers to staff it. I personally would like to see
> three people step forward and say they will work to improve b.p.o to make
> sure it functions as expected now and plan to improve it long-term. But I
> personally would settle for just two people actively working towards making
> b.p.o a tenable solution (the three person goal is just from experience of
> always wanting at least one backup even if someone goes on vacation or does
> an OSS detox).
>

It depends on what kind of maintenance we need.  In its current state
b.p.o is quite stable and requires little maintenance IMHO.
If instead we want to start adding (and fixing/maintaining) new
features, then the situation is different.

For the latter to happen, I would like to first see a PEP discussing
what desired features GitHub has that Roundup doesn't and vice versa
(Nick's list and Mariatta's slides and notes are a good starting
point, but they should be consolidated and include the feedback
expressed by other core devs on this thread).
>From there we can evaluate how difficult it would be to implement
those in Roundup and how this will compare with the difficulty of
switching to GitHub or some other system.

I already discussed with the Roundup devs about some of the features
listed by Nick, so I can comment on them:

> <Nick's list>
> Some examples of problems that would benefit from attention:
>
> - fixing the SSL/TLS connectivity issues

This is also being discussed at
https://github.com/python/psf-infra-meta/issues/4 (since it's an infra
issue).  One of the Roundup devs recently suggested a solution that
still needs to be tested.

> - making the issue tracker usable on mobile devices

The Roundup team has already some working prototype.

> - ability to edit the description for issues that evolve over time, not just the title
> - improved editing support for comments (both in initial formatting, and in being able to correct errors)

Comment editing shouldn't be too difficult to implement.  (For
"description", do you mean the first/initial message/comment?)

> - REST API access to tracker data

The code has been written, it needs to be merged and tested on a live
instance.  (I'm particularly concerned about security here, since it's
a whole new API that could expose new vulnerabilities, and even though
care has been taken when the code was written, I'm no security expert
and I would like if someone tried to break it in ways I'm not yet
aware of).

> - simplifying account creation (especially for folks that already have GitHub accounts)

Adding GitHub login to b.p.o should be doable too.

> - rationalising the metadata fields by asking which ones actually see significant use

These have been discussed and changed several times over the years.
With the REST API it will be easier to gather better usage stats.
FWIW there are some notes and ideas about it at
https://wiki.python.org/moin/TrackerDevelopmentPlanning#workflow and
https://wiki.python.org/moin/DesiredTrackerFeatures

> </Nick's list>

> But as of right now we have zero people supporting b.p.o (and GitHub has one
> with Mariatta which puts GH ahead in my book). Because of this, in my
> opinion this discussion shouldn't include b.p.o as an option until those
> volunteers materialize. We can argue GitHub versus GitLab versus some other
> issue tracker (open or closed source, self-hosted or service-hosted I
> personally don't care; heck write it from scratch like Warehouse if that's
> what it takes), but unless we get some people to step forward to help with
> b.p.o then I personally consider it our temporary solution until we figure
> out where we're going next with b.p.o and not a viable option in this
> discussion.
>

Even if the volunteers don't materialize (and I dematerialize), we
still have to determine if the cost of keep using b.p.o as is, is
greater than the cost of moving everything to a new system.

Best Regards,
Ezio Melotti

From mal at egenix.com  Sat Jun  2 18:19:06 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 3 Jun 2018 00:19:06 +0200
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <96b1f3ce-c1ef-094f-91a9-645e6a0bc430@udel.edu>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <96b1f3ce-c1ef-094f-91a9-645e6a0bc430@udel.edu>
Message-ID: <e32ade34-e307-821e-678f-e8753b576bd3@egenix.com>

Reading the comments in the thread and having used Github issues
myself for a few years now, I find the idea of moving from a
dedicated issue tracker we can easily customize to our needs
(or hire someone to do so via the PSF) to a simplistic tracker
add-on, which Github issues is, not a very promising approach.

Github issues are fine for simple projects, but I wouldn't even
want to use it for more than a hundred issues on Github.

As with many such proposals, if an existing system is seen to
be lacking in certain ways, the first thing people suggest is to
ditch it and move to this other new shiny thing or even
worse, suggest to build a new one.

I've rarely seen this work. Most of the time you end up having
a system with just different issues which leaves you with a
situation that's not better than before.

The time invested in migration and making sure that at least
part of the legacy will forward to the new solution is often
better invested in addressing the issues with the older system.

Yes, that's not as interesting and exciting as building something
new, but in the light of productivity and getting a working
solution, it's very often the better approach.

So if there is a real need to fix issues with bpo, then I'd
suggest to write up a proposal to get them fixed and find
a group of developers to work on these. Have the PSF provide
a grant to make it worthwhile and manage this project instead
of spending time with migrations.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jun 02 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/


From ethan at stoneleaf.us  Sat Jun  2 20:33:51 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 02 Jun 2018 17:33:51 -0700
Subject: [python-committers] number of active core devs [was: Comments on
 moving issues to GitHub]
In-Reply-To: <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
Message-ID: <5B13376F.3030109@stoneleaf.us>

On 06/02/2018 12:46 PM, Mariatta Wijaya wrote:

> And perhaps this is to be discussed in a separate thread: even though in the b.p.o we appear to have 170 committers,
> really there are 90 core devs (people who has commit right to CPython on GitHub). and out of those 90, I think only
> about half are currently active (since the migration to GitHub).

50% reduction in activity?  Ouch.

--
~Ethan~

From donald at stufft.io  Sat Jun  2 20:42:37 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 2 Jun 2018 20:42:37 -0400
Subject: [python-committers] number of active core devs [was: Comments
 on moving issues to GitHub]
In-Reply-To: <5B13376F.3030109@stoneleaf.us>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
Message-ID: <ACB80063-5F56-4AC4-82C0-F7BCF6A760E6@stufft.io>

Is that a 50% reduction or is that just 50% of the people who could be active are? 

Sent from my iPhone

> On Jun 2, 2018, at 8:33 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> 
>> On 06/02/2018 12:46 PM, Mariatta Wijaya wrote:
>> 
>> And perhaps this is to be discussed in a separate thread: even though in the b.p.o we appear to have 170 committers,
>> really there are 90 core devs (people who has commit right to CPython on GitHub). and out of those 90, I think only
>> about half are currently active (since the migration to GitHub).
> 
> 50% reduction in activity?  Ouch.
> 
> --
> ~Ethan~
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


From guido at python.org  Sat Jun  2 21:07:39 2018
From: guido at python.org (Guido van Rossum)
Date: Sat, 2 Jun 2018 18:07:39 -0700
Subject: [python-committers] number of active core devs [was: Comments
 on moving issues to GitHub]
In-Reply-To: <ACB80063-5F56-4AC4-82C0-F7BCF6A760E6@stufft.io>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <ACB80063-5F56-4AC4-82C0-F7BCF6A760E6@stufft.io>
Message-ID: <CAP7+vJKBD18WMBQ7FO6fQ=-ZLRn1hzzYe_ShJsvrmDn_fnwR9w@mail.gmail.com>

Sounds to me like these are probably just past committers who are no longer
active for whatever personal reasons, and took no action when we moved to
GitHub. We basically never remove the commit bit from anyone except by
request, and I only recall seeing one such request, ever. Some of them
probably expect to come back in the future (like Neil Schemenauer did). I
recall only one person who said they refused to move to GitHub (but AFAIK
we didn't remove their commit bit from b.p.o), so I don't think that we can
blame these numbers on the move to GitHub.

It's definitely disturbing that we have so few active committers though --
it means that a small number of people take on a lot of the load (my
intuition tells me it's even more skewed than Mariatta's numbers reveal).
The best course of action seems to be to take measures to acquire new
committers (and contributors), not to try and reactivate old inactive
committers.

On Sat, Jun 2, 2018 at 5:42 PM, Donald Stufft <donald at stufft.io> wrote:

> Is that a 50% reduction or is that just 50% of the people who could be
> active are?
>
> Sent from my iPhone
>
> > On Jun 2, 2018, at 8:33 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> >
> >> On 06/02/2018 12:46 PM, Mariatta Wijaya wrote:
> >>
> >> And perhaps this is to be discussed in a separate thread: even though
> in the b.p.o we appear to have 170 committers,
> >> really there are 90 core devs (people who has commit right to CPython
> on GitHub). and out of those 90, I think only
> >> about half are currently active (since the migration to GitHub).
> >
> > 50% reduction in activity?  Ouch.
> >
> > --
> > ~Ethan~
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180602/9fc14809/attachment-0001.html>

From brett at python.org  Sat Jun  2 22:49:24 2018
From: brett at python.org (Brett Cannon)
Date: Sat, 2 Jun 2018 19:49:24 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CACBhJdHBysO2LwdyHvjCUw7=6aZb_F8mXLB2paYVUmAVmm5-6Q@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <CAP1=2W4oRZ87ZfN35NuxRygaL8=C85hbuK2PyaVWp++yF2ox6g@mail.gmail.com>
 <CACBhJdHBysO2LwdyHvjCUw7=6aZb_F8mXLB2paYVUmAVmm5-6Q@mail.gmail.com>
Message-ID: <CAP1=2W4J32dPZuJTYpen_OrvC6S_dK-Dxj25ShKPKtPa7GKvqg@mail.gmail.com>

On Sat, 2 Jun 2018 at 14:58 Ezio Melotti <ezio.melotti at gmail.com> wrote:

> Hi,
>
> On Sat, Jun 2, 2018 at 10:26 PM, Brett Cannon <brett at python.org> wrote:
> >
> >
> > On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya <mariatta.wijaya at gmail.com>
> > wrote:
> >>
> >> [SNIP]
> >>
> >>> 2. Better support for core developers in the tracker.
> >>
> >>
> >> Not sure what you mean by "support"? There are only two maintainers of
> the
> >> bug tracker, they both are also Python core developers: Brett and Ezio.
> My
> >> personal opinion is: they're more valuable elsewhere instead of
> supporting
> >> the bug tracker. At its current state, the bug tracker is not ready to
> take
> >> up new contributors, and it will not be easy effort to onboard new bpo
> >> maintainers.
> >
> >
> > I actually wouldn't list me as a maintainer of b.p.o. I only have passing
> > knowledge of the code due to reviewing Ezio's changes to support the CLA
> > bot. It used to be RDM, Ezio, and Maciej, then DRM got busy, and then
> Maciej
> > got busy with helping move our hosting over to OpenShift and off of our
> > previously free hosting provider who sold their business (I also think
> > Maciej is also busy with other things). I don't know what Ezio's
> > availability currently sits at, but I have not heard from him recently.
> >
>
> I haven't actively worked on the tracker, but I kept an eye on it and
> acting when needed (e.g. yesterday I deployed a fix committed by
> Berker :).
> If needed I can pick it up again.
>

Great! So now we're tied for GitHub and b.p.o maintenance. ;)


> It should also be mentioned that before us, MvL also used to work on
> the tracker, and he added the Rietveld and openid integration (and
> these parts are not very well maintained now).
>

Oh, the list of former contributors was not meant to be exhaustive, more
just who I could remember during the GitHub transition days.


>
> > If you look at
> > https://hg.python.org/tracker/roundup/shortlog/bugs.python.org there
> has not
> > been an update to the repo's code in 8 months but there have been
> reported
> > issues as recently as yesterday:
> > http://psf.upfronthosting.co.za/roundup/meta/ .
> >
>
> This is a bit misleading:
> * that repo is updated only when Roundup is updated otherwise it sits
> there waiting for a new release. Roundup 1.6 is going to be released
> soon;
>

Sorry about that, I just grabbed the URL the contribution docs say to work
from for Roundup and didn't notice the extra URL for configuration.


> * the repo for our instance is
> https://hg.python.org/tracker/python-dev/shortlog/default .  This also
> didn't get many commits lately, however
> * the meta tracker also didn't get many new issues.  Only 7 issues in
> the metatracker have had any activity in the last 3 months, 2 are
> about SSL failure/certificates, 3 are about email ending up in the
> spam, one is about Google auth (however I'm not familiar with that
> part of the code), and the last one is a minor issue with a simple fix
> that needs to be tested/deployed.
>
> IOW there aren't many commits because there aren't that many issues
> with the code and because Roundup 1.6 hasn't been released yet.
>
>
> As mentioned above, the Roundup team is about to release Roundup 1.6.
> This release drops support for Python <2.7.
> AFAIU the infra team wanted to move/upgrade the machine running b.p.o
> (that is currently still running Python 2.6).  When that happens (and
> once Roundup 1.6 is released) we will upgrade it.
>
>
> > IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF
> > infrastructure team can re-start the instance if it falls over, but no
> one
> > is working on e.g. fixing log-in issues or any of the various UX issues
> we
> > are all painfully aware that b.p.o has.
> >
> > As I said at the language summit, if people want to keep b.p.o around
> then
> > we need to get some volunteers to staff it. I personally would like to
> see
> > three people step forward and say they will work to improve b.p.o to make
> > sure it functions as expected now and plan to improve it long-term. But I
> > personally would settle for just two people actively working towards
> making
> > b.p.o a tenable solution (the three person goal is just from experience
> of
> > always wanting at least one backup even if someone goes on vacation or
> does
> > an OSS detox).
> >
>
> It depends on what kind of maintenance we need.  In its current state
> b.p.o is quite stable and requires little maintenance IMHO.
>

I would be more inclined to agree if we didn't have so many login problems
(e.g. I have needed to manually go in and set people's passwords to reset
it due to issues getting password reset emails).


> If instead we want to start adding (and fixing/maintaining) new
> features, then the situation is different.
>
> For the latter to happen, I would like to first see a PEP discussing
> what desired features GitHub has that Roundup doesn't and vice versa
> (Nick's list and Mariatta's slides and notes are a good starting
> point, but they should be consolidated and include the feedback
> expressed by other core devs on this thread).
>

I believe the plan is to have a round of proposals, including staying on
b.p.o (but I'm not driving this so I could be wrong :) .


> From there we can evaluate how difficult it would be to implement
> those in Roundup and how this will compare with the difficulty of
> switching to GitHub or some other system.
>
> I already discussed with the Roundup devs about some of the features
> listed by Nick, so I can comment on them:
>
> > <Nick's list>
> > Some examples of problems that would benefit from attention:
> >
> > - fixing the SSL/TLS connectivity issues
>
> This is also being discussed at
> https://github.com/python/psf-infra-meta/issues/4 (since it's an infra
> issue).  One of the Roundup devs recently suggested a solution that
> still needs to be tested.
>
> > - making the issue tracker usable on mobile devices
>
> The Roundup team has already some working prototype.
>
> > - ability to edit the description for issues that evolve over time, not
> just the title
> > - improved editing support for comments (both in initial formatting, and
> in being able to correct errors)
>
> Comment editing shouldn't be too difficult to implement.  (For
> "description", do you mean the first/initial message/comment?)
>
> > - REST API access to tracker data
>
> The code has been written, it needs to be merged and tested on a live
> instance.  (I'm particularly concerned about security here, since it's
> a whole new API that could expose new vulnerabilities, and even though
> care has been taken when the code was written, I'm no security expert
> and I would like if someone tried to break it in ways I'm not yet
> aware of).
>
> > - simplifying account creation (especially for folks that already have
> GitHub accounts)
>
> Adding GitHub login to b.p.o should be doable too.
>
> > - rationalising the metadata fields by asking which ones actually see
> significant use
>
> These have been discussed and changed several times over the years.
> With the REST API it will be easier to gather better usage stats.
> FWIW there are some notes and ideas about it at
> https://wiki.python.org/moin/TrackerDevelopmentPlanning#workflow and
> https://wiki.python.org/moin/DesiredTrackerFeatures
>
> > </Nick's list>
>
> > But as of right now we have zero people supporting b.p.o (and GitHub has
> one
> > with Mariatta which puts GH ahead in my book). Because of this, in my
> > opinion this discussion shouldn't include b.p.o as an option until those
> > volunteers materialize. We can argue GitHub versus GitLab versus some
> other
> > issue tracker (open or closed source, self-hosted or service-hosted I
> > personally don't care; heck write it from scratch like Warehouse if
> that's
> > what it takes), but unless we get some people to step forward to help
> with
> > b.p.o then I personally consider it our temporary solution until we
> figure
> > out where we're going next with b.p.o and not a viable option in this
> > discussion.
> >
>
> Even if the volunteers don't materialize (and I dematerialize), we
> still have to determine if the cost of keep using b.p.o as is, is
> greater than the cost of moving everything to a new system.
>

Yep.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180602/a7f382cc/attachment.html>

From ncoghlan at gmail.com  Sun Jun  3 01:44:01 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 3 Jun 2018 15:44:01 +1000
Subject: [python-committers] number of active core devs [was: Comments
 on moving issues to GitHub]
In-Reply-To: <CAP7+vJKBD18WMBQ7FO6fQ=-ZLRn1hzzYe_ShJsvrmDn_fnwR9w@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <ACB80063-5F56-4AC4-82C0-F7BCF6A760E6@stufft.io>
 <CAP7+vJKBD18WMBQ7FO6fQ=-ZLRn1hzzYe_ShJsvrmDn_fnwR9w@mail.gmail.com>
Message-ID: <CADiSq7cuZuu8jwrHKxBpHNW=YoC7BFrR4HDn7cpf8iEsz1Sqzw@mail.gmail.com>

On 3 June 2018 at 11:07, Guido van Rossum <guido at python.org> wrote:

> Sounds to me like these are probably just past committers who are no
> longer active for whatever personal reasons, and took no action when we
> moved to GitHub. We basically never remove the commit bit from anyone
> except by request, and I only recall seeing one such request, ever. Some of
> them probably expect to come back in the future (like Neil Schemenauer
> did). I recall only one person who said they refused to move to GitHub (but
> AFAIK we didn't remove their commit bit from b.p.o), so I don't think that
> we can blame these numbers on the move to GitHub.
>

OpenHub [1] shows the average rate of commits declining fairly steadily
since the exceptional ~40-commits-per-day spike in September 2016 down to
our current steady state of ~4 commits per day (we still get spikes up to
10+ commits per day for PyCon US and the core dev sprints, but not of the
magnitude of previous sprints). Those metrics only record the actual commit
rate (not the code churn rate), so some of that may be due to the switch to
a PR based workflow with pre-merge CI reducing the volume of fix-up
commits, and I also don't know how the switch from our
patch-and-merge-forward workflow in Mercurial to the
squash-merge-and-cherry-pick workflow in git affects the accounting.

While the switch to GitHub does show up clearly in the "contributor" stats
on OpenHub, the move to git is also when the VCS metadata started recording
the committer and author information separately in a way that OpenHub can
read (rather than only providing the patch author information in the commit
message and NEWS entry), so someone would need to go back and extract the
real pre-git contributor metrics to make that a valid comparison.

On the issue management & patch review side of things, while
https://bugs.python.org/issue?@template=stats does show the number of open
issues with patches declining slightly post-migration, it's since leveled
off and then started climbing again.

So based on the numbers we're seeing, my own assessment would be that the
move to GitHub didn't hurt, but it also didn't really help address the
review bottleneck problem either (which surprises me as much as it does
anyone else - perhaps now that patch reviews are more pleasant to engage
in, we're also making them more thorough?).

Cheers,
Nick.

[1] https://www.openhub.net/p/python

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180603/1fe79a80/attachment-0001.html>

From ncoghlan at gmail.com  Sun Jun  3 03:00:18 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 3 Jun 2018 17:00:18 +1000
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAP1=2W4J32dPZuJTYpen_OrvC6S_dK-Dxj25ShKPKtPa7GKvqg@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <CAP1=2W4oRZ87ZfN35NuxRygaL8=C85hbuK2PyaVWp++yF2ox6g@mail.gmail.com>
 <CACBhJdHBysO2LwdyHvjCUw7=6aZb_F8mXLB2paYVUmAVmm5-6Q@mail.gmail.com>
 <CAP1=2W4J32dPZuJTYpen_OrvC6S_dK-Dxj25ShKPKtPa7GKvqg@mail.gmail.com>
Message-ID: <CADiSq7fWyiApOKwbk1K4gFxRspWAqZPCyU==ELjC2SObk7FGWQ@mail.gmail.com>

On 3 June 2018 at 12:49, Brett Cannon <brett at python.org> wrote:

>
> On Sat, 2 Jun 2018 at 14:58 Ezio Melotti <ezio.melotti at gmail.com> wrote:
>
> Even if the volunteers don't materialize (and I dematerialize), we
>> still have to determine if the cost of keep using b.p.o as is, is
>> greater than the cost of moving everything to a new system.
>>
>
> Yep.
>

Since even Mariatta's GitHub migration proposal is likely to require
changes to bugs.python.org (most notably adding the REST API to better
enable automated issue management), something that would be nice to see is
for b.p.o to migrate over to the common "Support repo" model we've adopted
(i.e. hosted on GitHub using the integrated issue tracker for repo-specific
issues).

I'll also email Maciej & EW Durbin ([1]) to see if they've had a chance to
discuss the rehosting plans for bugs.python.org yet.

Cheers,
Nick.

[1] the PSF's new Director of Infrastructure [2], who some folks may
already know from his extensive work on PyPI and other parts of the PSF
infrastructure, as well as chairing Python US in 2018/19
[2] https://twitter.com/EWDurbin/status/1001519029767561216

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180603/713795df/attachment.html>

From antoine at python.org  Sun Jun  3 04:27:37 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sun, 3 Jun 2018 10:27:37 +0200
Subject: [python-committers] number of active core devs
In-Reply-To: <5B13376F.3030109@stoneleaf.us>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
Message-ID: <f4a9da91-91f4-c8e3-2063-da02949144fc@python.org>


That's not the symptom of a ? 50% reduction in activity ?.  10 years
ago, it was already the case that many core developers were inactive
(not necessarily the same as today!).

That said, it is true that core development activity continues to
shrink, at least according to this particular metric:
https://github.com/python/cpython/graphs/contributors

As I predicted, while being a net improvement in workflow for existing
contributors, the migration to Github doesn't seem to make CPython a
more attractive project for new contributors.

Regards

Antoine.



Le 03/06/2018 ? 02:33, Ethan Furman a ?crit?:
> On 06/02/2018 12:46 PM, Mariatta Wijaya wrote:
> 
>> And perhaps this is to be discussed in a separate thread: even though in the b.p.o we appear to have 170 committers,
>> really there are 90 core devs (people who has commit right to CPython on GitHub). and out of those 90, I think only
>> about half are currently active (since the migration to GitHub).
> 
> 50% reduction in activity?  Ouch.
> 
> --
> ~Ethan~
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

From berker.peksag at gmail.com  Sun Jun  3 06:36:55 2018
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Sun, 3 Jun 2018 13:36:55 +0300
Subject: [python-committers] number of active core devs
In-Reply-To: <f4a9da91-91f4-c8e3-2063-da02949144fc@python.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <f4a9da91-91f4-c8e3-2063-da02949144fc@python.org>
Message-ID: <CAF4280KC=2bqyLFSE9_MjeLEzYrTqhpj1XjdB60D1hwoA5LPdA@mail.gmail.com>

On Sun, Jun 3, 2018 at 11:27 AM, Antoine Pitrou <antoine at python.org> wrote:
> That said, it is true that core development activity continues to
> shrink, at least according to this particular metric:
> https://github.com/python/cpython/graphs/contributors

I think the pre-GitHub stats includes merge commits too:

    https://github.com/python/cpython/commits?after=a801cf164be7c62b6a6dba47ff91d6c3edb67729+34&author=berkerpeksag

(Look at the commits from Feb 7, 2017.)

It's normal to have less commits on master since we are now doing
"merge in master-cherrypick into maintenance branches" instead of
"merge from X.Y to X.Y+1 to master".

--Berker

From antoine at python.org  Sun Jun  3 14:55:09 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sun, 3 Jun 2018 20:55:09 +0200
Subject: [python-committers] number of active core devs
In-Reply-To: <CAF4280KC=2bqyLFSE9_MjeLEzYrTqhpj1XjdB60D1hwoA5LPdA@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <f4a9da91-91f4-c8e3-2063-da02949144fc@python.org>
 <CAF4280KC=2bqyLFSE9_MjeLEzYrTqhpj1XjdB60D1hwoA5LPdA@mail.gmail.com>
Message-ID: <a45408b7-91da-4982-c928-04add124e164@python.org>


Le 03/06/2018 ? 12:36, Berker Peksa? a ?crit?:
> On Sun, Jun 3, 2018 at 11:27 AM, Antoine Pitrou <antoine at python.org> wrote:
>> That said, it is true that core development activity continues to
>> shrink, at least according to this particular metric:
>> https://github.com/python/cpython/graphs/contributors
> 
> I think the pre-GitHub stats includes merge commits too:

The graph says ? Contributions to master, excluding merge commits ?.

>     https://github.com/python/cpython/commits?after=a801cf164be7c62b6a6dba47ff91d6c3edb67729+34&author=berkerpeksag
> 
> (Look at the commits from Feb 7, 2017.)

If I take this one for example:
https://github.com/python/cpython/commit/ee0ee9ae8e9111a5ce8a09e7b705cfd380394ce7

it has two parents so supposedly it's a merge commit.

Regards

Antoine.

From brett at python.org  Sun Jun  3 15:44:55 2018
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Jun 2018 12:44:55 -0700
Subject: [python-committers] number of active core devs [was: Comments
 on moving issues to GitHub]
In-Reply-To: <CAP7+vJKBD18WMBQ7FO6fQ=-ZLRn1hzzYe_ShJsvrmDn_fnwR9w@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <ACB80063-5F56-4AC4-82C0-F7BCF6A760E6@stufft.io>
 <CAP7+vJKBD18WMBQ7FO6fQ=-ZLRn1hzzYe_ShJsvrmDn_fnwR9w@mail.gmail.com>
Message-ID: <CAP1=2W6z_NWJhfSf6Cvom=yqbU_NC2jYgJtX4J3Z8Rm4L9pegg@mail.gmail.com>

On Sat, 2 Jun 2018 at 18:08 Guido van Rossum <guido at python.org> wrote:

> Sounds to me like these are probably just past committers who are no
> longer active for whatever personal reasons, and took no action when we
> moved to GitHub. We basically never remove the commit bit from anyone
> except by request, and I only recall seeing one such request, ever. Some of
> them probably expect to come back in the future (like Neil Schemenauer
> did). I recall only one person who said they refused to move to GitHub (but
> AFAIK we didn't remove their commit bit from b.p.o), so I don't think that
> we can blame these numbers on the move to GitHub.
>

This assessment is accurate. The b.p.o count is everyone who has ever been
a core dev since we moved there (October 2006), while the GitHub number is
anyone who said "I want to keep my commit bit" and provided me with their
GitHub username when we moved plus any new members to the team.

I actually plan to clean up the list on b.p.o at some point and at least
take off folks' commit marker if the person doesn't have their GitHub
username set (I don't know if removing people's Contributor role should be
done as well since if someone has not set their GH username they probably
don't know how our current workflow works either). Based on the number
after that and personal motivation I will see if I want to bother doing a
direct correlation with the actual list from GitHub.


>
> It's definitely disturbing that we have so few active committers though --
> it means that a small number of people take on a lot of the load (my
> intuition tells me it's even more skewed than Mariatta's numbers reveal).
> The best course of action seems to be to take measures to acquire new
> committers (and contributors), not to try and reactivate old inactive
> committers.
>

I will admit that I think we lost some core devs who had zero exposure to
GitHub prior to switching and never found the motivation to ramp up on the
new workflow.

As for acquiring new committers, I think we should try to mine who is
authoring code as well as who is contributing reviews of PRs. That way we
can bubble up folks who are helping out in that regard (I personally would
also be interested in who is committing code, but I don't think that will
be as useful). The former can be done with a git checkout, the latter will
require going through the GitHub API to get the data.


>
> On Sat, Jun 2, 2018 at 5:42 PM, Donald Stufft <donald at stufft.io> wrote:
>
>> Is that a 50% reduction or is that just 50% of the people who could be
>> active are?
>>
>> Sent from my iPhone
>>
>> > On Jun 2, 2018, at 8:33 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> >
>> >> On 06/02/2018 12:46 PM, Mariatta Wijaya wrote:
>> >>
>> >> And perhaps this is to be discussed in a separate thread: even though
>> in the b.p.o we appear to have 170 committers,
>> >> really there are 90 core devs (people who has commit right to CPython
>> on GitHub). and out of those 90, I think only
>> >> about half are currently active (since the migration to GitHub).
>> >
>> > 50% reduction in activity?  Ouch.
>> >
>> > --
>> > ~Ethan~
>> > _______________________________________________
>> > python-committers mailing list
>> > python-committers at python.org
>> > https://mail.python.org/mailman/listinfo/python-committers
>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180603/c8630ccd/attachment.html>

From tjreedy at udel.edu  Sun Jun  3 16:23:08 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 3 Jun 2018 16:23:08 -0400
Subject: [python-committers] Wrongly stopping merges discourages merging.
Message-ID: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>

When we used hg, core dev committers could actually commit to the 
repository when they judged it appropriate.  When we moved to github, 
Brett, with whoever's approval, decided that we should no longer be 
trusted to make commits without approval of a couple of mindless robots. 
  However, the premise that the robots should be trusted is false.  So I 
again request that there be a manual override for when the robots are 
obviously giving false failures.

Exhibit 1. For at least a couple of weeksin may, faults in the asyncio 
test (and another) caused the asyncio test to randomly fail about half 
the time.  With one retest, each CI bot failed about 1/4 the time.  At 
least one bot of the two bots failed about 1/2 the time.  The AppVeyor 
queue ballooned.

One could decrease the frustration and time to success (but only partly) 
  by only re-starting the bot that failed.  Doing so for Travis is 
fairly easy.  Doing so with AppVeyor is obscure and error prone.

I twice requested that the randomly failing tests be disabled.  Victor 
said he wanted to keep monitoring what they did.  I think he overly 
discounted the pain and frustration of having good merges blocked.  I 
think either 1) bad tests should be disabled, or 2. the CI code should 
be able to ignore failures by bad tests, or 3. responsible core devs 
should be able to.

Exhibit 2. AppVeyor is badly broken.

This morning Cheryl Sabella submitted a nice patch fixing an annoying 
behavior of IDLE's editor/shell/output windows.  The CI tests passed, 
the patch worked great, it only needed expansion of the placeholder 
blurb.  I was really excited.

With some trepidation, I made the edit.  Unfortunately, both CI bots 
rerun the code tests even when the code is unchanged.  Blurb edits 
should be treated as doc-only changes, with only the blurb rechecked.

My trepidation turned out to be well-founded.  My excitement is gone. 
After an error, AppVeyor just quit without reporting any failure cause.
https://ci.appveyor.com/project/python/cpython/build/3.8build16869

Since then, there have been 2 successes and 7 similar unexplained failures.
https://ci.appveyor.com/project/python/cpython/history
https://ci.appveyor.com/project/python/cpython/build/3.6build16871/job/c2q80njh9clnfgjt
https://ci.appveyor.com/project/python/cpython/build/3.8build16872
https://ci.appveyor.com/project/python/cpython/build/3.7build16873
https://ci.appveyor.com/project/python/cpython/build/3.8build16874
https://ci.appveyor.com/project/python/cpython/build/3.6build16876/job/t9nyt59wkwcn68nk
https://ci.appveyor.com/project/python/cpython/build/3.8build16877
https://ci.appveyor.com/project/python/cpython/build/3.8build16878

The last is my restart.  The time wasted by this broken blockbot is time 
not spent doing something useful.  I would really like to have this 
patch in the .rc in a week -- along with a few others that should follow.

Guido once asked what is off-putting about being a core developer.  This 
is one thing.

Terry Jan Reedy

From zachary.ware+pydev at gmail.com  Sun Jun  3 16:47:39 2018
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Sun, 3 Jun 2018 15:47:39 -0500
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
Message-ID: <CAKJDb-Nu1r2=HG_SfbQU44KGD43GfEbjS-F-UK4khxkW3G_2pg@mail.gmail.com>

Hi Terry,

I have an email going out to AppVeyor with you CCed, we'll see what
kind of response we get (probably tomorrow).  In the meantime, I'll
look into disabling largefile tests, or test_mmap specifically on
AppVeyor to see whether that helps the situation.

On Sun, Jun 3, 2018 at 3:23 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> When we used hg, core dev committers could actually commit to the repository
> when they judged it appropriate.  When we moved to github, Brett, with
> whoever's approval, decided that we should no longer be trusted to make
> commits without approval of a couple of mindless robots.  However, the
> premise that the robots should be trusted is false.  So I again request that
> there be a manual override for when the robots are obviously giving false
> failures.
>
> Exhibit 1. For at least a couple of weeksin may, faults in the asyncio test
> (and another) caused the asyncio test to randomly fail about half the time.
> With one retest, each CI bot failed about 1/4 the time.  At least one bot of
> the two bots failed about 1/2 the time.  The AppVeyor queue ballooned.
>
> One could decrease the frustration and time to success (but only partly)  by
> only re-starting the bot that failed.  Doing so for Travis is fairly easy.
> Doing so with AppVeyor is obscure and error prone.
>
> I twice requested that the randomly failing tests be disabled.  Victor said
> he wanted to keep monitoring what they did.  I think he overly discounted
> the pain and frustration of having good merges blocked.  I think either 1)
> bad tests should be disabled, or 2. the CI code should be able to ignore
> failures by bad tests, or 3. responsible core devs should be able to.
>
> Exhibit 2. AppVeyor is badly broken.
>
> This morning Cheryl Sabella submitted a nice patch fixing an annoying
> behavior of IDLE's editor/shell/output windows.  The CI tests passed, the
> patch worked great, it only needed expansion of the placeholder blurb.  I
> was really excited.
>
> With some trepidation, I made the edit.  Unfortunately, both CI bots rerun
> the code tests even when the code is unchanged.  Blurb edits should be
> treated as doc-only changes, with only the blurb rechecked.
>
> My trepidation turned out to be well-founded.  My excitement is gone. After
> an error, AppVeyor just quit without reporting any failure cause.
> https://ci.appveyor.com/project/python/cpython/build/3.8build16869
>
> Since then, there have been 2 successes and 7 similar unexplained failures.
> https://ci.appveyor.com/project/python/cpython/history
> https://ci.appveyor.com/project/python/cpython/build/3.6build16871/job/c2q80njh9clnfgjt
> https://ci.appveyor.com/project/python/cpython/build/3.8build16872
> https://ci.appveyor.com/project/python/cpython/build/3.7build16873
> https://ci.appveyor.com/project/python/cpython/build/3.8build16874
> https://ci.appveyor.com/project/python/cpython/build/3.6build16876/job/t9nyt59wkwcn68nk
> https://ci.appveyor.com/project/python/cpython/build/3.8build16877
> https://ci.appveyor.com/project/python/cpython/build/3.8build16878
>
> The last is my restart.  The time wasted by this broken blockbot is time not
> spent doing something useful.  I would really like to have this patch in the
> .rc in a week -- along with a few others that should follow.
>
> Guido once asked what is off-putting about being a core developer.  This is
> one thing.
>
> Terry Jan Reedy
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
Zach

From vstinner at redhat.com  Sun Jun  3 17:19:56 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sun, 3 Jun 2018 23:19:56 +0200
Subject: [python-committers] number of active core devs
In-Reply-To: <f4a9da91-91f4-c8e3-2063-da02949144fc@python.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <f4a9da91-91f4-c8e3-2063-da02949144fc@python.org>
Message-ID: <CA+3bQGE8SmdpGBqKqq66OE3PRqScLDSkTSgYKEz52pujAJv-tA@mail.gmail.com>

2018-06-03 10:27 GMT+02:00 Antoine Pitrou <antoine at python.org>:
> That said, it is true that core development activity continues to
> shrink, at least according to this particular metric:
> https://github.com/python/cpython/graphs/contributors

I also noticed a very significant drop in the number of commits in the
master branch. I prefer OpenHub, since it's possible to zoom on the
last 5 years, and the mouse gives the number of commits per month:
https://www.openhub.net/p/python/commits/summary

A raw estimation is that the average was 400 commits per month 2 years
ago, and in 2017 it was closer to 200 commits per month: 2x less
commits in the master branch.

I recall that before GitHub, it was very common that I pushed directly
a change to fix a typo, to change a timeout value, or even more
frequently... to fix my previous commit. Before GitHub, we had
basically no pre-commit tests, so it's very common to break the
buildbots. It was also more common to push a feature into multiple
single commits. Sometimes to get commits easier to read, easier to
review, and to get "atomic changes".

With GitHub, there is a very high pressure on preventing any
regression on Linux and Windows, since we have Travis CI (Linux) and
AppVeyor (Windows) CIs. I also guess (but I'm not sure) that there is
more pressure on the review. IMHO core developers and contributors
spend more time on review than previously.

In short, the feature commit + fix the commit became a single commit :-)

Well, that's my optimistic guess :-)

Since there is more pressure on the review , all changes are more
visible thanks to pull requests, I push less quick fixes, and try to
spend more time on large changes.

Victor

From tim.peters at gmail.com  Sun Jun  3 17:34:10 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 3 Jun 2018 16:34:10 -0500
Subject: [python-committers] number of active core devs
In-Reply-To: <CA+3bQGE8SmdpGBqKqq66OE3PRqScLDSkTSgYKEz52pujAJv-tA@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <f4a9da91-91f4-c8e3-2063-da02949144fc@python.org>
 <CA+3bQGE8SmdpGBqKqq66OE3PRqScLDSkTSgYKEz52pujAJv-tA@mail.gmail.com>
Message-ID: <CAExdVNnY10DPSmUwOvpdVtwdtE-ugd_MyjHGw8ycLFDX0sPzfw@mail.gmail.com>

[Victor Stinner <vstinner at redhat.com>]

> ...
> In short, the feature commit + fix the commit became a single commit :-)
>

I'd give a lot of weight to that - if I cared about counting commits at
all, which I don't ;-)

I just recently learned enough about git and github to get my feet wet
again.  My first patch was to add some patterns to cpython's .gitignore to
stop worrying about garbage files unique to the editors I use (C.tom and
*.bak).

So I made a branch, created a push/pull/whatever_it's_called, and a
reviewer noted there was a better way to get what I was after (a local
git-ignore file that would apply to _all_ things I use git for).

So I closed the proposed change unmerged and deleted the branch.

In the old days, I would have just committed it, and then later reverted
the change after someone educated me.

So the github workflow is responsible for reducing my master commits 100%,
from 2 to 0 so far ;-)

And I think that's a good thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180603/2630fb9b/attachment.html>

From vstinner at redhat.com  Sun Jun  3 17:46:30 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sun, 3 Jun 2018 23:46:30 +0200
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
Message-ID: <CA+3bQGEU1ujZKL+tPba2TH+NbtngDxqOaB8tZLPxEPVpE8m17Q@mail.gmail.com>

2018-06-03 22:23 GMT+02:00 Terry Reedy <tjreedy at udel.edu>:
> Exhibit 1. For at least a couple of weeksin may, faults in the asyncio test
> (and another) caused the asyncio test to randomly fail about half the time.
> With one retest, each CI bot failed about 1/4 the time.  At least one bot of
> the two bots failed about 1/2 the time.  The AppVeyor queue ballooned.

I only told a few core developers: in February, I had a burn out and I
stopped everything related to Python during 3 months. I only restarted
slowly to contribute to Python in May. I moved to a new team inside
Red Hat, and my job is now to maintain Python for Red Hat.

When I saw that Ned Deily had troubles to get a release two weeks ago,
I looked a the status of the CI. As I expected, the CIs became again
very unstable. A CI is a puppy, if nobody cares of it, it dies slowly
:-( I'm sure that many core devs fixed dozens of bugs, but the
annoying part are tests which only fail randomly. It's hard to spot
them and hard to debug them. If you have a single flaky test, it's
fine. When you have two or three of them, slowly the failure rate
becomes larger than 25% and then 50%...


> One could decrease the frustration and time to success (but only partly)  by
> only re-starting the bot that failed.  Doing so for Travis is fairly easy.
> Doing so with AppVeyor is obscure and error prone.

Ah? From a GitHub PR, I click on the failed AppVeyor job (click on
"details"): at the top, there is a "[Re-build PR]".

I logged into App Veyor one or two weeks ago, thanks to a cookie,
AppVeyor now remembers me :-)

It's just two clicks once you are logged in, no?

Are you confused by the [New build] button? I never used that one :-)


> I twice requested that the randomly failing tests be disabled.  Victor said
> he wanted to keep monitoring what they did.  I think he overly discounted
> the pain and frustration of having good merges blocked.  I think either 1)
> bad tests should be disabled, or 2. the CI code should be able to ignore
> failures by bad tests, or 3. responsible core devs should be able to.

My rationale is that once a test is disabled: everybody quickly
forgets and we will keep the test as disabled for the next 5 years.

Just one example: I skipped test_ftplib.test_check_hostname() 5 months
ago... Ok, who looked at this *failing* test?

There is an open issue, right:
https://bugs.python.org/issue32706

But who cares of this issue?

Ok, let's come back to asyncio: one asyncio test started to fail,
right. Yury Selivanov, Andrew Sveltov and me spend a lot of time to
look at these tests. The sendfile tests were unable and have been
fixed. But the SSL test was weird. In fact, it wasn't a bug in the
test, but in asyncio directly!

https://bugs.python.org/issue33674

So the test helped us to spot a very tricky race condition. I prefer
that we suffered a few days than an user had such bug in production...


> Exhibit 2. AppVeyor is badly broken.
>
> This morning Cheryl Sabella submitted a nice patch fixing an annoying
> behavior of IDLE's editor/shell/output windows.  The CI tests passed, the
> patch worked great, it only needed expansion of the placeholder blurb.  I
> was really excited.
>
> With some trepidation, I made the edit.  Unfortunately, both CI bots rerun
> the code tests even when the code is unchanged.  Blurb edits should be
> treated as doc-only changes, with only the blurb rechecked.
>
> My trepidation turned out to be well-founded.  My excitement is gone. After
> an error, AppVeyor just quit without reporting any failure cause.
> https://ci.appveyor.com/project/python/cpython/build/3.8build16869

It's the first time that I see such weird behaviour on AppVeyor.

Would you mind to open a new issue to track it, please?


> Guido once asked what is off-putting about being a core developer.  This is one thing.

There are different options:

* Make AppVeyor faster: can we pay to get parallel builds? can we just
ask to get more parallel builds? run less tests? (ex: as Zach wrote,
disable the "largefile" resource)
* Make AppVeyor non blocking on pull requests
* Remove AppVeyor

If possible, I would prefer to keep a blocking CI on pull requests.
Each time we disabled AppVeyor, Windows quickly became broken.

VSTS might be a solution here, but I simply ignored this CI, since I
was busy enough to fix bugs on the other CIs.

Fixing CI failures is not a funny job and it's not rewarding. But it's
the price to pay to get an excellent quality.

If you ask my opinion, I prefer that everybody stop working until the
CI is repaired. Skipped tests only slowly reduce the quality.

Victor

From vstinner at redhat.com  Sun Jun  3 17:57:07 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sun, 3 Jun 2018 23:57:07 +0200
Subject: [python-committers] AppVeyor slowed down?
Message-ID: <CA+3bQGHGGKCMJwBKWvU4zLQZG2ZDE6=6Nr4zsYvHCuzJVyKpzg@mail.gmail.com>

Hi,

Is it just me or AppVeyor became slower than it was a few months ago?

First of all, for AppVeyor, *all* builds are in the same queue and we
are only allowed to run one job in parallel. Currently, AppVeyor is
the obvious bottleneck of our workflow. It directly limits the number
of commits that we can merge per day.

Hopefully, thanks to Mariatta, backports are now merged as soon as CIs
pass if a core developer approved the PR. It's no longer needed to
watch the CIs to know when the Merge button will be enabed!

I looked more closely at AppVeyor last week since it took up to 2
hours to run tests on my CI, preventing me to merge it.

(Q1) AppVeyor runs again tests once the PR is merge. Was it the point
of running tests in each branch since... nobody look at test results
of these builds? Would it be possible to disable these jobs?

(Q2) AppVeyor runs tests twice on 3.6: VS 2015 and VS2017. It *seems*
(I'm not sure) that there are tested... sequentially. Each job takes
12 min so the who build takes 24 min... It seems like the official
binary on python.org is built on VS 2015: so maybe we could only keep
VS 2015 for the blocking CI, and maybe add a new buildbot (if there is
not already one) for VS 2017?

(Q3) How can we be allowed to run more jobs in parallel? Would it be free?

Zachary Ware wrote that he disabled the "largefile" resources of
Python test suite, so tests should now run faster.

Last week I found the cool build history:
https://ci.appveyor.com/project/python/cpython/history

It helped me to find some tests which fail randomly. I noticed that
they fail much more frequently than what I expected. Most developers
just schedule a new build.

Victor

From vstinner at redhat.com  Sun Jun  3 18:05:57 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 4 Jun 2018 00:05:57 +0200
Subject: [python-committers] number of active core devs [was: Comments
 on moving issues to GitHub]
In-Reply-To: <CAP7+vJKBD18WMBQ7FO6fQ=-ZLRn1hzzYe_ShJsvrmDn_fnwR9w@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <ACB80063-5F56-4AC4-82C0-F7BCF6A760E6@stufft.io>
 <CAP7+vJKBD18WMBQ7FO6fQ=-ZLRn1hzzYe_ShJsvrmDn_fnwR9w@mail.gmail.com>
Message-ID: <CA+3bQGFM3Ov8Xo1__zeHDjiDOZFm+8LNkU6JGesSzydWds4Mhw@mail.gmail.com>

2018-06-03 3:07 GMT+02:00 Guido van Rossum <guido at python.org>:
> The best course of action seems to be to take measures to acquire new
> committers (and contributors), not to try and reactivate old inactive
> committers.

My advice is to spend more time on mentoring and less time to write
code yourself. In my experience, it's the fatest way to train a
contributor to become a core developer.

I almost succeeded to train someone up to a core dev, but the
contributor asked to not become a core right now for personal reasons.
I hope that it will happen soon ;-)

Victor

From vstinner at redhat.com  Sun Jun  3 20:56:59 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 4 Jun 2018 02:56:59 +0200
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <CA+3bQGEU1ujZKL+tPba2TH+NbtngDxqOaB8tZLPxEPVpE8m17Q@mail.gmail.com>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
 <CA+3bQGEU1ujZKL+tPba2TH+NbtngDxqOaB8tZLPxEPVpE8m17Q@mail.gmail.com>
Message-ID: <CA+3bQGFro_-t0BMDV_+6SXTNZRLr-qmwXHGt6hZoLR2nwAS4Sg@mail.gmail.com>

I reported two issues:

"AppVeyor builds interrupted before tests complete"
https://bugs.python.org/issue33764

"AppVeyor didn't start on my PR 7365"
https://bugs.python.org/issue33765

Victor

From steve.dower at python.org  Sun Jun  3 22:30:50 2018
From: steve.dower at python.org (Steve Dower)
Date: Sun, 3 Jun 2018 19:30:50 -0700
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <CA+3bQGEU1ujZKL+tPba2TH+NbtngDxqOaB8tZLPxEPVpE8m17Q@mail.gmail.com>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
 <CA+3bQGEU1ujZKL+tPba2TH+NbtngDxqOaB8tZLPxEPVpE8m17Q@mail.gmail.com>
Message-ID: <mailman.194.1528079461.2800.python-committers@python.org>

We probably have enough data on the VSTS builds by now to see whether they are comparable/faster than AppVeyor. Obviously the idea of doing that work was to be able to migrate builds if it made sense, and if we decide not to then they get ripped out (non-binding PR checks are confusing IMHO, particularly when they duplicate required checks).

I have no idea whether that discussion is still ongoing on core-workflow, but if it seems better then maybe it?s time? Anyone can view the VSTS build history starting from https://python.visualstudio.com/cpython/_build and browsing into the build definition of interest.

Top-posted from my Windows 10 phone

From: Victor Stinner
Sent: Sunday, June 3, 2018 14:47
To: Terry Reedy
Cc: python-committers
Subject: Re: [python-committers] Wrongly stopping merges discourages merging.

2018-06-03 22:23 GMT+02:00 Terry Reedy <tjreedy at udel.edu>:
> Exhibit 1. For at least a couple of weeksin may, faults in the asyncio test
> (and another) caused the asyncio test to randomly fail about half the time.
> With one retest, each CI bot failed about 1/4 the time.  At least one bot of
> the two bots failed about 1/2 the time.  The AppVeyor queue ballooned.

I only told a few core developers: in February, I had a burn out and I
stopped everything related to Python during 3 months. I only restarted
slowly to contribute to Python in May. I moved to a new team inside
Red Hat, and my job is now to maintain Python for Red Hat.

When I saw that Ned Deily had troubles to get a release two weeks ago,
I looked a the status of the CI. As I expected, the CIs became again
very unstable. A CI is a puppy, if nobody cares of it, it dies slowly
:-( I'm sure that many core devs fixed dozens of bugs, but the
annoying part are tests which only fail randomly. It's hard to spot
them and hard to debug them. If you have a single flaky test, it's
fine. When you have two or three of them, slowly the failure rate
becomes larger than 25% and then 50%...


> One could decrease the frustration and time to success (but only partly)  by
> only re-starting the bot that failed.  Doing so for Travis is fairly easy.
> Doing so with AppVeyor is obscure and error prone.

Ah? From a GitHub PR, I click on the failed AppVeyor job (click on
"details"): at the top, there is a "[Re-build PR]".

I logged into App Veyor one or two weeks ago, thanks to a cookie,
AppVeyor now remembers me :-)

It's just two clicks once you are logged in, no?

Are you confused by the [New build] button? I never used that one :-)


> I twice requested that the randomly failing tests be disabled.  Victor said
> he wanted to keep monitoring what they did.  I think he overly discounted
> the pain and frustration of having good merges blocked.  I think either 1)
> bad tests should be disabled, or 2. the CI code should be able to ignore
> failures by bad tests, or 3. responsible core devs should be able to.

My rationale is that once a test is disabled: everybody quickly
forgets and we will keep the test as disabled for the next 5 years.

Just one example: I skipped test_ftplib.test_check_hostname() 5 months
ago... Ok, who looked at this *failing* test?

There is an open issue, right:
https://bugs.python.org/issue32706

But who cares of this issue?

Ok, let's come back to asyncio: one asyncio test started to fail,
right. Yury Selivanov, Andrew Sveltov and me spend a lot of time to
look at these tests. The sendfile tests were unable and have been
fixed. But the SSL test was weird. In fact, it wasn't a bug in the
test, but in asyncio directly!

https://bugs.python.org/issue33674

So the test helped us to spot a very tricky race condition. I prefer
that we suffered a few days than an user had such bug in production...


> Exhibit 2. AppVeyor is badly broken.
>
> This morning Cheryl Sabella submitted a nice patch fixing an annoying
> behavior of IDLE's editor/shell/output windows.  The CI tests passed, the
> patch worked great, it only needed expansion of the placeholder blurb.  I
> was really excited.
>
> With some trepidation, I made the edit.  Unfortunately, both CI bots rerun
> the code tests even when the code is unchanged.  Blurb edits should be
> treated as doc-only changes, with only the blurb rechecked.
>
> My trepidation turned out to be well-founded.  My excitement is gone. After
> an error, AppVeyor just quit without reporting any failure cause.
> https://ci.appveyor.com/project/python/cpython/build/3.8build16869

It's the first time that I see such weird behaviour on AppVeyor.

Would you mind to open a new issue to track it, please?


> Guido once asked what is off-putting about being a core developer.  This is one thing.

There are different options:

* Make AppVeyor faster: can we pay to get parallel builds? can we just
ask to get more parallel builds? run less tests? (ex: as Zach wrote,
disable the "largefile" resource)
* Make AppVeyor non blocking on pull requests
* Remove AppVeyor

If possible, I would prefer to keep a blocking CI on pull requests.
Each time we disabled AppVeyor, Windows quickly became broken.

VSTS might be a solution here, but I simply ignored this CI, since I
was busy enough to fix bugs on the other CIs.

Fixing CI failures is not a funny job and it's not rewarding. But it's
the price to pay to get an excellent quality.

If you ask my opinion, I prefer that everybody stop working until the
CI is repaired. Skipped tests only slowly reduce the quality.

Victor
_______________________________________________
python-committers mailing list
python-committers at python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180603/7a10e902/attachment.html>

From nad at python.org  Sun Jun  3 23:30:11 2018
From: nad at python.org (Ned Deily)
Date: Sun, 3 Jun 2018 23:30:11 -0400
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <40zf7g22qHz12yjK@mail.python.org>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
 <CA+3bQGEU1ujZKL+tPba2TH+NbtngDxqOaB8tZLPxEPVpE8m17Q@mail.gmail.com>
 <40zf7g22qHz12yjK@mail.python.org>
Message-ID: <19F3FBBC-C938-41C8-A600-87AE21DB2547@python.org>

On Jun 3, 2018, at 22:30, Steve Dower <steve.dower at python.org> wrote:
> We probably have enough data on the VSTS builds by now to see whether they are comparable/faster than AppVeyor. Obviously the idea of doing that work was to be able to migrate builds if it made sense, and if we decide not to then they get ripped out (non-binding PR checks are confusing IMHO, particularly when they duplicate required checks).
>  
> I have no idea whether that discussion is still ongoing on core-workflow, but if it seems better then maybe it?s time? Anyone can view the VSTS build history starting from https://python.visualstudio.com/cpython/_build and browsing into the build definition of interest.

My gut feel from observing the progress of PRs over the past couple of weeks is that the VSTS CI builds are faster and much less problematic than the AppVeyor builds have been.  That said, one significant Windows test bottleneck was identified last week (largefile tests in test_mmap) on some buildbots and was disabled.  We've now also disabled it on AppVeyor, once AppVeyor starts running our tests again, and I've suggested it be disabled on the VSTS Windows CI runs as well.  That, along with a number of other test fixes made over the past week, may help eliminate with AppVeyor.  But, at this point, I think we should seriously consider dropping mandatory AppVeyor CI runs in favor of the VSTS ones.

Brett, do you concur?  And, if so, can you make it happen?

--
  Ned Deily
  nad at python.org -- []


From brett at python.org  Mon Jun  4 11:02:00 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Jun 2018 08:02:00 -0700
Subject: [python-committers] Turning off AppVeyor as required
Message-ID: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>

Victor noticed that AppVeyor stopped building about 19 hours ago, leading
to it blocking all open PRs. I have gone ahead and switched off requiring
AppVeyor for now, so please pay attention to at least the Windows VSTS
status check to make sure you're not breaking Windows by accident.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180604/58344f59/attachment.html>

From vstinner at redhat.com  Mon Jun  4 11:33:06 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 4 Jun 2018 17:33:06 +0200
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
Message-ID: <CA+3bQGH9hnSOGNOU_-96zyvn3=DTsQ=ZagoCOBX6EG7avTdAgw@mail.gmail.com>

Hum. For backports, should we stop to approve PRs in advance?
miss-islington currently ignores VSTS status and so may merge a
backport even if VSTS Windows fails.

Victor

2018-06-04 17:02 GMT+02:00 Brett Cannon <brett at python.org>:
> Victor noticed that AppVeyor stopped building about 19 hours ago, leading to
> it blocking all open PRs. I have gone ahead and switched off requiring
> AppVeyor for now, so please pay attention to at least the Windows VSTS
> status check to make sure you're not breaking Windows by accident.
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From brett at python.org  Mon Jun  4 12:18:11 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Jun 2018 09:18:11 -0700
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <CA+3bQGH9hnSOGNOU_-96zyvn3=DTsQ=ZagoCOBX6EG7avTdAgw@mail.gmail.com>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
 <CA+3bQGH9hnSOGNOU_-96zyvn3=DTsQ=ZagoCOBX6EG7avTdAgw@mail.gmail.com>
Message-ID: <CAP1=2W4G94Funv-+e8D9rGwE9QRG9TKAjvF2eyXo=HEcytfLwg@mail.gmail.com>

I'm currently not in the mood to argue about VSTS' stability so I don't
feel comfortable flipping that on as a requirement quite yet.

On Mon, 4 Jun 2018 at 08:33 Victor Stinner <vstinner at redhat.com> wrote:

> Hum. For backports, should we stop to approve PRs in advance?
> miss-islington currently ignores VSTS status and so may merge a
> backport even if VSTS Windows fails.
>
> Victor
>
> 2018-06-04 17:02 GMT+02:00 Brett Cannon <brett at python.org>:
> > Victor noticed that AppVeyor stopped building about 19 hours ago,
> leading to
> > it blocking all open PRs. I have gone ahead and switched off requiring
> > AppVeyor for now, so please pay attention to at least the Windows VSTS
> > status check to make sure you're not breaking Windows by accident.
> >
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180604/9392a756/attachment.html>

From vstinner at redhat.com  Mon Jun  4 12:32:59 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 4 Jun 2018 18:32:59 +0200
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <CAP1=2W4G94Funv-+e8D9rGwE9QRG9TKAjvF2eyXo=HEcytfLwg@mail.gmail.com>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
 <CA+3bQGH9hnSOGNOU_-96zyvn3=DTsQ=ZagoCOBX6EG7avTdAgw@mail.gmail.com>
 <CAP1=2W4G94Funv-+e8D9rGwE9QRG9TKAjvF2eyXo=HEcytfLwg@mail.gmail.com>
Message-ID: <CA+3bQGGwAOLdcj8-juZ2=srONwFt3gMFfANYnfaXc_GH-cjHng@mail.gmail.com>

2018-06-04 18:18 GMT+02:00 Brett Cannon <brett at python.org>:
> I'm currently not in the mood to argue about VSTS' stability so I don't feel
> comfortable flipping that on as a requirement quite yet.

I don't suggest to make it mandatory right now.

I will try to keep on eye on VSTS ;-)

Victor

From mariatta.wijaya at gmail.com  Mon Jun  4 12:34:55 2018
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Mon, 4 Jun 2018 09:34:55 -0700
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <CAP1=2W4G94Funv-+e8D9rGwE9QRG9TKAjvF2eyXo=HEcytfLwg@mail.gmail.com>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
 <CA+3bQGH9hnSOGNOU_-96zyvn3=DTsQ=ZagoCOBX6EG7avTdAgw@mail.gmail.com>
 <CAP1=2W4G94Funv-+e8D9rGwE9QRG9TKAjvF2eyXo=HEcytfLwg@mail.gmail.com>
Message-ID: <CAGbohnbU-NaO8S_mTw5nHWfgiMSeWib05HUiAAzbJZ6NcDnf2w@mail.gmail.com>

>
> miss-islington currently ignores VSTS status


No it does not yet ignore VSTS status. If VSTS status failed, it will not
automerge.

Mariatta

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180604/bdd2b6c5/attachment.html>

From steve.dower at python.org  Mon Jun  4 12:46:19 2018
From: steve.dower at python.org (Steve Dower)
Date: Mon, 4 Jun 2018 09:46:19 -0700
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <CA+3bQGGwAOLdcj8-juZ2=srONwFt3gMFfANYnfaXc_GH-cjHng@mail.gmail.com>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
 <CA+3bQGH9hnSOGNOU_-96zyvn3=DTsQ=ZagoCOBX6EG7avTdAgw@mail.gmail.com>
 <CAP1=2W4G94Funv-+e8D9rGwE9QRG9TKAjvF2eyXo=HEcytfLwg@mail.gmail.com>
 <CA+3bQGGwAOLdcj8-juZ2=srONwFt3gMFfANYnfaXc_GH-cjHng@mail.gmail.com>
Message-ID: <9f1c62f7-df2c-ed02-e003-cbe504fd5f56@python.org>

On 04Jun2018 0932, Victor Stinner wrote:
> 2018-06-04 18:18 GMT+02:00 Brett Cannon <brett at python.org>:
>> I'm currently not in the mood to argue about VSTS' stability so I don't feel
>> comfortable flipping that on as a requirement quite yet.
> 
> I don't suggest to make it mandatory right now.
> 
> I will try to keep on eye on VSTS ;-)

FWIW I had a quick look through the history of Windows commit builds on 
VSTS. There last three failures were:
  * test_subprocess getting wedged and the build timed out (surprisingly 
gracefully though, it sent a Ctrl+C to the app so we still got all the 
output)
  * Tcl/tk and/or OpenSSL build got stuck (this was on 3.6 - we don't 
build these every time as of 3.7)
  * test_asyncio issues

Since the last of those issue, there have been 50-ish successful builds. 
(Note that I looked at commit builds, not PR builds, so I wouldn't have 
to wade through every single PR to see if it was a genuine bug.)

You can review the history here:

Windows commits: 
https://python.visualstudio.com/cpython/_build/index?definitionId=4&_a=history&path=%5C
Windows PRs: 
https://python.visualstudio.com/cpython/_build/index?definitionId=9&_a=history&path=%5C
macOS commits: 
https://python.visualstudio.com/cpython/_build/index?definitionId=5&_a=history&path=%5C
macOS PRs: 
https://python.visualstudio.com/cpython/_build/index?definitionId=8&_a=history&path=%5C
Linux commits: 
https://python.visualstudio.com/cpython/_build/index?definitionId=6&_a=history&path=%5C
Linux PRs: 
https://python.visualstudio.com/cpython/_build/index?definitionId=7&_a=history&path=%5C
Linux with code coverage: 
https://python.visualstudio.com/cpython/_build/index?definitionId=13&_a=history&path=%5C 
(both commits and PRs right now, still undecided how to best make use of 
this run, as we don't seem to report coverage stats anywhere?)

Cheers,
Steve

From brett at python.org  Mon Jun  4 12:54:12 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Jun 2018 09:54:12 -0700
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <19F3FBBC-C938-41C8-A600-87AE21DB2547@python.org>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
 <CA+3bQGEU1ujZKL+tPba2TH+NbtngDxqOaB8tZLPxEPVpE8m17Q@mail.gmail.com>
 <40zf7g22qHz12yjK@mail.python.org>
 <19F3FBBC-C938-41C8-A600-87AE21DB2547@python.org>
Message-ID: <CAP1=2W7FTn68M=ZaJxKrXhjM7yXy_iBiqUkoRP5FGvSzzzUZQg@mail.gmail.com>

On Sun, 3 Jun 2018 at 20:30 Ned Deily <nad at python.org> wrote:

> On Jun 3, 2018, at 22:30, Steve Dower <steve.dower at python.org> wrote:
> > We probably have enough data on the VSTS builds by now to see whether
> they are comparable/faster than AppVeyor. Obviously the idea of doing that
> work was to be able to migrate builds if it made sense, and if we decide
> not to then they get ripped out (non-binding PR checks are confusing IMHO,
> particularly when they duplicate required checks).
> >
> > I have no idea whether that discussion is still ongoing on
> core-workflow, but if it seems better then maybe it?s time? Anyone can view
> the VSTS build history starting from
> https://python.visualstudio.com/cpython/_build and browsing into the
> build definition of interest.
>
> My gut feel from observing the progress of PRs over the past couple of
> weeks is that the VSTS CI builds are faster and much less problematic than
> the AppVeyor builds have been.  That said, one significant Windows test
> bottleneck was identified last week (largefile tests in test_mmap) on some
> buildbots and was disabled.  We've now also disabled it on AppVeyor, once
> AppVeyor starts running our tests again, and I've suggested it be disabled
> on the VSTS Windows CI runs as well.  That, along with a number of other
> test fixes made over the past week, may help eliminate with AppVeyor.  But,
> at this point, I think we should seriously consider dropping mandatory
> AppVeyor CI runs in favor of the VSTS ones.
>
> Brett, do you concur?  And, if so, can you make it happen?
>

I'll start a discussion over on core-workflow.

-Brett


>
> --
>   Ned Deily
>   nad at python.org -- []
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180604/f07d8f19/attachment-0001.html>

From vstinner at redhat.com  Mon Jun  4 13:06:07 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 4 Jun 2018 19:06:07 +0200
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <9f1c62f7-df2c-ed02-e003-cbe504fd5f56@python.org>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
 <CA+3bQGH9hnSOGNOU_-96zyvn3=DTsQ=ZagoCOBX6EG7avTdAgw@mail.gmail.com>
 <CAP1=2W4G94Funv-+e8D9rGwE9QRG9TKAjvF2eyXo=HEcytfLwg@mail.gmail.com>
 <CA+3bQGGwAOLdcj8-juZ2=srONwFt3gMFfANYnfaXc_GH-cjHng@mail.gmail.com>
 <9f1c62f7-df2c-ed02-e003-cbe504fd5f56@python.org>
Message-ID: <CA+3bQGEfhsDAedBDSJWBZmRa-6+H+E+SmA3WYWAXMU=OgSo7vA@mail.gmail.com>

By the way, Python 2.7 doesn't have AppVeyor nor VSTS?

Is there a plan to add VSTS to Python 2.7?

Victor

2018-06-04 18:46 GMT+02:00 Steve Dower <steve.dower at python.org>:
> On 04Jun2018 0932, Victor Stinner wrote:
>>
>> 2018-06-04 18:18 GMT+02:00 Brett Cannon <brett at python.org>:
>>>
>>> I'm currently not in the mood to argue about VSTS' stability so I don't
>>> feel
>>> comfortable flipping that on as a requirement quite yet.
>>
>>
>> I don't suggest to make it mandatory right now.
>>
>> I will try to keep on eye on VSTS ;-)
>
>
> FWIW I had a quick look through the history of Windows commit builds on
> VSTS. There last three failures were:
>  * test_subprocess getting wedged and the build timed out (surprisingly
> gracefully though, it sent a Ctrl+C to the app so we still got all the
> output)
>  * Tcl/tk and/or OpenSSL build got stuck (this was on 3.6 - we don't build
> these every time as of 3.7)
>  * test_asyncio issues
>
> Since the last of those issue, there have been 50-ish successful builds.
> (Note that I looked at commit builds, not PR builds, so I wouldn't have to
> wade through every single PR to see if it was a genuine bug.)
>
> You can review the history here:
>
> Windows commits:
> https://python.visualstudio.com/cpython/_build/index?definitionId=4&_a=history&path=%5C
> Windows PRs:
> https://python.visualstudio.com/cpython/_build/index?definitionId=9&_a=history&path=%5C
> macOS commits:
> https://python.visualstudio.com/cpython/_build/index?definitionId=5&_a=history&path=%5C
> macOS PRs:
> https://python.visualstudio.com/cpython/_build/index?definitionId=8&_a=history&path=%5C
> Linux commits:
> https://python.visualstudio.com/cpython/_build/index?definitionId=6&_a=history&path=%5C
> Linux PRs:
> https://python.visualstudio.com/cpython/_build/index?definitionId=7&_a=history&path=%5C
> Linux with code coverage:
> https://python.visualstudio.com/cpython/_build/index?definitionId=13&_a=history&path=%5C
> (both commits and PRs right now, still undecided how to best make use of
> this run, as we don't seem to report coverage stats anywhere?)
>
> Cheers,
> Steve
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From steve.dower at python.org  Mon Jun  4 13:31:19 2018
From: steve.dower at python.org (Steve Dower)
Date: Mon, 4 Jun 2018 10:31:19 -0700
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <CA+3bQGEfhsDAedBDSJWBZmRa-6+H+E+SmA3WYWAXMU=OgSo7vA@mail.gmail.com>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
 <CA+3bQGH9hnSOGNOU_-96zyvn3=DTsQ=ZagoCOBX6EG7avTdAgw@mail.gmail.com>
 <CAP1=2W4G94Funv-+e8D9rGwE9QRG9TKAjvF2eyXo=HEcytfLwg@mail.gmail.com>
 <CA+3bQGGwAOLdcj8-juZ2=srONwFt3gMFfANYnfaXc_GH-cjHng@mail.gmail.com>
 <9f1c62f7-df2c-ed02-e003-cbe504fd5f56@python.org>
 <CA+3bQGEfhsDAedBDSJWBZmRa-6+H+E+SmA3WYWAXMU=OgSo7vA@mail.gmail.com>
Message-ID: <mailman.11.1528133490.20306.python-committers@python.org>

Correct, and I wasn't planning on it. The default VSTS machines don?t have the right compiler, and I?m not about to start managing VMs for 2.7 at this stage.

Top-posted from my Windows 10 phone

From: Victor Stinner
Sent: Monday, June 4, 2018 10:07
To: Steve Dower
Cc: python-committers
Subject: Re: [python-committers] Turning off AppVeyor as required

By the way, Python 2.7 doesn't have AppVeyor nor VSTS?

Is there a plan to add VSTS to Python 2.7?

Victor

2018-06-04 18:46 GMT+02:00 Steve Dower <steve.dower at python.org>:
> On 04Jun2018 0932, Victor Stinner wrote:
>>
>> 2018-06-04 18:18 GMT+02:00 Brett Cannon <brett at python.org>:
>>>
>>> I'm currently not in the mood to argue about VSTS' stability so I don't
>>> feel
>>> comfortable flipping that on as a requirement quite yet.
>>
>>
>> I don't suggest to make it mandatory right now.
>>
>> I will try to keep on eye on VSTS ;-)
>
>
> FWIW I had a quick look through the history of Windows commit builds on
> VSTS. There last three failures were:
>  * test_subprocess getting wedged and the build timed out (surprisingly
> gracefully though, it sent a Ctrl+C to the app so we still got all the
> output)
>  * Tcl/tk and/or OpenSSL build got stuck (this was on 3.6 - we don't build
> these every time as of 3.7)
>  * test_asyncio issues
>
> Since the last of those issue, there have been 50-ish successful builds.
> (Note that I looked at commit builds, not PR builds, so I wouldn't have to
> wade through every single PR to see if it was a genuine bug.)
>
> You can review the history here:
>
> Windows commits:
> https://python.visualstudio.com/cpython/_build/index?definitionId=4&_a=history&path=%5C
> Windows PRs:
> https://python.visualstudio.com/cpython/_build/index?definitionId=9&_a=history&path=%5C
> macOS commits:
> https://python.visualstudio.com/cpython/_build/index?definitionId=5&_a=history&path=%5C
> macOS PRs:
> https://python.visualstudio.com/cpython/_build/index?definitionId=8&_a=history&path=%5C
> Linux commits:
> https://python.visualstudio.com/cpython/_build/index?definitionId=6&_a=history&path=%5C
> Linux PRs:
> https://python.visualstudio.com/cpython/_build/index?definitionId=7&_a=history&path=%5C
> Linux with code coverage:
> https://python.visualstudio.com/cpython/_build/index?definitionId=13&_a=history&path=%5C
> (both commits and PRs right now, still undecided how to best make use of
> this run, as we don't seem to report coverage stats anywhere?)
>
> Cheers,
> Steve
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180604/5df53b10/attachment.html>

From brett at python.org  Mon Jun  4 13:54:08 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Jun 2018 10:54:08 -0700
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
Message-ID: <CAP1=2W7K3itDwu68jibcBd-mop47pZnr0E-6NUqqbqDQx8dxZw@mail.gmail.com>

On Sun, 3 Jun 2018 at 13:23 Terry Reedy <tjreedy at udel.edu> wrote:

> When we used hg, core dev committers could actually commit to the
> repository when they judged it appropriate.  When we moved to github,
> Brett, with whoever's approval,


Since this seems very much directed at me, I should mention any authority I
have has either come from Guido and/or the PEP process. If people are
unhappy with my work then please feel free to bring it up and we can
discuss having my privileges taken away.


> decided that we should no longer be
> trusted to make commits without approval of a couple of mindless robots.
>   However, the premise that the robots should be trusted is false.  So I
> again request that there be a manual override for when the robots are
> obviously giving false failures.
>

Please realize that every time we have switched off CI, we have ended up
with a broken branch, so it's a trade-off between these occasional hiccups
or occasionally broken branches (and as Victor has pointed out, we are not
always good as a group about making sure we notice when stuff breaks). Also
note that because we now have branches that are almost always stable we
have users who actually run from a checkout directly instead of waiting for
a release (which also benefits us by helping to surface bugs earlier than
e.g. an RC).


>
> Exhibit 1. For at least a couple of weeksin may, faults in the asyncio
> test (and another) caused the asyncio test to randomly fail about half
> the time.  With one retest, each CI bot failed about 1/4 the time.  At
> least one bot of the two bots failed about 1/2 the time.  The AppVeyor
> queue ballooned.
>
> One could decrease the frustration and time to success (but only partly)
>   by only re-starting the bot that failed.  Doing so for Travis is
> fairly easy.  Doing so with AppVeyor is obscure and error prone.
>
> I twice requested that the randomly failing tests be disabled.  Victor
> said he wanted to keep monitoring what they did.  I think he overly
> discounted the pain and frustration of having good merges blocked.  I
> think either 1) bad tests should be disabled, or 2. the CI code should
> be able to ignore failures by bad tests, or 3. responsible core devs
> should be able to.
>
> Exhibit 2. AppVeyor is badly broken.
>
> This morning Cheryl Sabella submitted a nice patch fixing an annoying
> behavior of IDLE's editor/shell/output windows.  The CI tests passed,
> the patch worked great, it only needed expansion of the placeholder
> blurb.  I was really excited.
>
> With some trepidation, I made the edit.  Unfortunately, both CI bots
> rerun the code tests even when the code is unchanged.  Blurb edits
> should be treated as doc-only changes, with only the blurb rechecked.
>
> My trepidation turned out to be well-founded.  My excitement is gone.
> After an error, AppVeyor just quit without reporting any failure cause.
> https://ci.appveyor.com/project/python/cpython/build/3.8build16869
>
> Since then, there have been 2 successes and 7 similar unexplained failures.
> https://ci.appveyor.com/project/python/cpython/history
>
> https://ci.appveyor.com/project/python/cpython/build/3.6build16871/job/c2q80njh9clnfgjt
> https://ci.appveyor.com/project/python/cpython/build/3.8build16872
> https://ci.appveyor.com/project/python/cpython/build/3.7build16873
> https://ci.appveyor.com/project/python/cpython/build/3.8build16874
>
> https://ci.appveyor.com/project/python/cpython/build/3.6build16876/job/t9nyt59wkwcn68nk
> https://ci.appveyor.com/project/python/cpython/build/3.8build16877
> https://ci.appveyor.com/project/python/cpython/build/3.8build16878
>
> The last is my restart.  The time wasted by this broken blockbot is time
> not spent doing something useful.  I would really like to have this
> patch in the .rc in a week -- along with a few others that should follow.
>
> Guido once asked what is off-putting about being a core developer.  This
> is one thing.
>

So both examples seem very focused on AppVeyor and the first one somewhat
at CI overall. As stated in another email, I have turned off AppVeyor being
required so 1.5 of these issues have been dealt with (and based on a PR I
looked it the requirement retroactively went away for all open PRs).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180604/a0061ccf/attachment-0001.html>

From donald at stufft.io  Mon Jun  4 14:49:14 2018
From: donald at stufft.io (Donald Stufft)
Date: Mon, 4 Jun 2018 14:49:14 -0400
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <CAP1=2W7K3itDwu68jibcBd-mop47pZnr0E-6NUqqbqDQx8dxZw@mail.gmail.com>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
 <CAP1=2W7K3itDwu68jibcBd-mop47pZnr0E-6NUqqbqDQx8dxZw@mail.gmail.com>
Message-ID: <6A094644-0CDF-426A-A3A2-1A2CB5D73FAF@stufft.io>

I?d also add that it is generally a good thing that people with power and a voice (e.g. the core devs) are having a similar experience that an external contributor would. This is our best line of defense against the external contributor experience degrading to a bad place. By having core devs share a similar experience, we can get feedback like the one about AppVeyor and try to improve things for everyone, instead of simply giving core devs a way to opt out of the pain. 

Sent from my iPhone

> On Jun 4, 2018, at 1:54 PM, Brett Cannon <brett at python.org> wrote:
> 
> Please realize that every time we have switched off CI, we have ended up with a broken branch, so it's a trade-off between these occasional hiccups or occasionally broken branches (and as Victor has pointed out, we are not always good as a group about making sure we notice when stuff breaks). Also note that because we now have branches that are almost always stable we have users who actually run from a checkout directly instead of waiting for a release (which also benefits us by helping to surface bugs earlier than e.g. an RC).


From guido at python.org  Mon Jun  4 14:51:27 2018
From: guido at python.org (Guido van Rossum)
Date: Mon, 4 Jun 2018 11:51:27 -0700
Subject: [python-committers] Wrongly stopping merges discourages merging.
In-Reply-To: <6A094644-0CDF-426A-A3A2-1A2CB5D73FAF@stufft.io>
References: <d8d681e8-57b8-b4df-f53a-deb486ce3c1e@udel.edu>
 <CAP1=2W7K3itDwu68jibcBd-mop47pZnr0E-6NUqqbqDQx8dxZw@mail.gmail.com>
 <6A094644-0CDF-426A-A3A2-1A2CB5D73FAF@stufft.io>
Message-ID: <CAP7+vJKdfvGrGBxKP=n-2JrP6SV7mdCTrA+N9X6YdQRDGnMDmA@mail.gmail.com>

+1. For example for mypy I use the "triangular" git setup even though as a
mypy core dev I could simply push my branch to the main repo.

On Mon, Jun 4, 2018 at 11:49 AM, Donald Stufft <donald at stufft.io> wrote:

> I?d also add that it is generally a good thing that people with power and
> a voice (e.g. the core devs) are having a similar experience that an
> external contributor would. This is our best line of defense against the
> external contributor experience degrading to a bad place. By having core
> devs share a similar experience, we can get feedback like the one about
> AppVeyor and try to improve things for everyone, instead of simply giving
> core devs a way to opt out of the pain.
>
> Sent from my iPhone
>
> > On Jun 4, 2018, at 1:54 PM, Brett Cannon <brett at python.org> wrote:
> >
> > Please realize that every time we have switched off CI, we have ended up
> with a broken branch, so it's a trade-off between these occasional hiccups
> or occasionally broken branches (and as Victor has pointed out, we are not
> always good as a group about making sure we notice when stuff breaks). Also
> note that because we now have branches that are almost always stable we
> have users who actually run from a checkout directly instead of waiting for
> a release (which also benefits us by helping to surface bugs earlier than
> e.g. an RC).
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180604/0a62dfeb/attachment.html>

From vstinner at redhat.com  Mon Jun  4 16:38:57 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 4 Jun 2018 22:38:57 +0200
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
Message-ID: <CA+3bQGGqcMw-Mj30LZ9gbXnU+Fu5hykJ3KpgnRGZwTFdO8s2yA@mail.gmail.com>

I have very good news from AppVeyor:

* AppVeyor runs again jobs on pull requests: it's back!
* Issue with quotas: it was a disk issue, it was on their side and
it's now fixed.
* AppVeyor donate us additional parallel job to the python account!

Moreover:

* They proposed us to extend the timeout to 90 minuts. Hopefully, a
full build (download + compile + run tests) takes usually less than 15
min, so it's fine.
* They explained me how to disable AppVeyor on branches to only run
tests on pull requests. "Do not build feature branches with open Pull
Requests in UI (skip_branch_with_pr: true if you use YAML)." seems the
safest option. Another option is: "disable Pushes event in GitHub
Webhook settings" but I don't undestand if it only impacts AppVeyor or
all our hooks.

Thank you very much AppVeyor! See my support issue for the details:

http://help.appveyor.com/discussions/problems/14532-cpython-exceeded-allowed-resource-quotas-what-are-these-quotas-can-them-be-increased

Victor

2018-06-04 17:02 GMT+02:00 Brett Cannon <brett at python.org>:
> Victor noticed that AppVeyor stopped building about 19 hours ago, leading to
> it blocking all open PRs. I have gone ahead and switched off requiring
> AppVeyor for now, so please pay attention to at least the Windows VSTS
> status check to make sure you're not breaking Windows by accident.
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From steve at pearwood.info  Mon Jun  4 20:47:25 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 5 Jun 2018 10:47:25 +1000
Subject: [python-committers] number of active core devs [was: Comments
 on moving issues to GitHub]
In-Reply-To: <CAP1=2W6z_NWJhfSf6Cvom=yqbU_NC2jYgJtX4J3Z8Rm4L9pegg@mail.gmail.com>
References: <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <5B13376F.3030109@stoneleaf.us>
 <ACB80063-5F56-4AC4-82C0-F7BCF6A760E6@stufft.io>
 <CAP7+vJKBD18WMBQ7FO6fQ=-ZLRn1hzzYe_ShJsvrmDn_fnwR9w@mail.gmail.com>
 <CAP1=2W6z_NWJhfSf6Cvom=yqbU_NC2jYgJtX4J3Z8Rm4L9pegg@mail.gmail.com>
Message-ID: <20180605004724.GV12683@ando.pearwood.info>

On Sun, Jun 03, 2018 at 12:44:55PM -0700, Brett Cannon wrote:

> I will admit that I think we lost some core devs who had zero exposure to
> GitHub prior to switching and never found the motivation to ramp up on the
> new workflow.

*raises hand*

I'm one of them. Not that I was a prolific core dev, but I did have 
commit priviliges.

I'm not a full-time programmer, and the discipline of using VCS does not 
come naturally to me. Without doing it daily, or even weekly, it always 
feels like friction rather than something helpful. (Intellectually, I 
understand the benefits, but emotionally it is another story.)

It took me a long while to get used to hg, and just when I had, we 
changed to git and everything I thought I knew was wrong :-)

Add to that some unrelated changes in my personal life, and my 
motivation to learn the new workflow dropped to not just zero but became 
negative. But I've keep up with the community, and I feel my motivation 
gradually increasing. It's now above zero and just waiting on me finding 
time :-)

(Given today's news about Microsoft and Github, I'll probably just learn 
the Github workflow in time for us to move to something different again 
*wink*)

Long ago, when we first started discussing this move, I asked if we had 
an objective measure of what would count as "success" in the move. I'm 
not sure I was ever answered, but given the motives expressed at the 
time ("make it easier to recruit core devs" I think was one of them) I 
don't think the move has been a complete success.

That's not to call it a failure: it clearly hasn't been that, and to 
those who know git and like github, it has clearly been a win for them. 
But I think it is important to acknowledge which of our goals were met 
and which were not.


-- 
Steve

From ncoghlan at gmail.com  Tue Jun  5 08:07:53 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 5 Jun 2018 22:07:53 +1000
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CADiSq7fWyiApOKwbk1K4gFxRspWAqZPCyU==ELjC2SObk7FGWQ@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>
 <CAGbohna2J5VT7=gOHANYpzxWmvfxw8Nz0mrtxrR5ypT_vbbsow@mail.gmail.com>
 <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org>
 <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org>
 <CAOMjWk=Hm8atTL+QmDW-DUKpMpahW2do2gv=EHo1TM59F5CHAA@mail.gmail.com>
 <40ykBg6d1DzFqpT@mail.python.org>
 <CAGbohnbF8T=AtcEfdw=PYn7MZo0VHnhG5kdKHRV=x69EEgQDEw@mail.gmail.com>
 <CAP1=2W4oRZ87ZfN35NuxRygaL8=C85hbuK2PyaVWp++yF2ox6g@mail.gmail.com>
 <CACBhJdHBysO2LwdyHvjCUw7=6aZb_F8mXLB2paYVUmAVmm5-6Q@mail.gmail.com>
 <CAP1=2W4J32dPZuJTYpen_OrvC6S_dK-Dxj25ShKPKtPa7GKvqg@mail.gmail.com>
 <CADiSq7fWyiApOKwbk1K4gFxRspWAqZPCyU==ELjC2SObk7FGWQ@mail.gmail.com>
Message-ID: <CADiSq7dyASG-uX-TJ4sm-+bpPZBJiXhmgrtFVJyXPTH-q-ey5g@mail.gmail.com>

On 3 June 2018 at 17:00, Nick Coghlan <ncoghlan at gmail.com> wrote:

> I'll also email Maciej & EW Durbin ([1]) to see if they've had a chance to
> discuss the rehosting plans for bugs.python.org yet.
>

The status update here is that Maciej has been bringing Ernest up to speed
on the preparatory work that has already been done, but there's still some
further work to be done before they can provide an ETA for the actual
migration more precise than "in the not too distant future" (my
understanding is that the main items still being reviewed are the preferred
final destination for the PostgreSQL database, as well as how best to
actually execute the cutover).

Maciej also noted that while he's definitely interested in continuing to
work on bugs.python.org maintenance activities, he can't reply directly to
this thread since it's a CPython-committers-only list.

That's a very fair point, so I'd suggest that we move any further
discussion over to the core-workflow list. If folks don't want to subscribe
to yet-another-mailing-list, that's one that we've already migrated to
Mailman 3, so it has a web interface available at
https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ (my
recommendation is to use your GitHub account to sign in, but there are
other social-auth login options, as well as the traditional email+password
approach).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180605/1d6fa803/attachment-0001.html>

From steve.dower at python.org  Tue Jun  5 18:53:46 2018
From: steve.dower at python.org (Steve Dower)
Date: Tue, 5 Jun 2018 15:53:46 -0700
Subject: [python-committers] Core Dev Sprints
Message-ID: <c78e2372-4f58-cc3d-4f90-34710b4d1b11@python.org>

Hi all

Just a quick update to let everyone know that I've started sending out 
invites for the sprints.

We have a limited number of *funded* places available, but room to 
accommodate more people actually being there. So the way I'm approaching 
this is by working down a somewhat arbitrarily-ordered list (with a bias 
towards previous attendees, recent contributions, and newer core 
developers) and sending out only as many invitations as we have funded 
places.

As I hear that people either can't make it or don't need funding, I'll 
invite the next person. So if you didn't receive an invite today, it 
doesn't mean you aren't getting one. And if you _did_ receive an invite 
today, the sooner you reply the more it'll help out everyone else.

Also, if you know already that you don't need PSF funding to attend but 
you haven't got an invite yet, please reply to me off-list and let me 
know. Our space is really only limited by "how many people in our large 
room is too many" (the fire marshal says about 120 people...), so you 
won't miss out. But you are able to skip the queue, as it were.

Finally, I am not the person you want designing the t-shirt for this 
event. If someone wants to step up and design/produce a t-shirt, now is 
the time to claim that responsibility. Otherwise we'll probably just try 
and off-load old Microsoft swag ;)

Cheers,
Steve

From vstinner at redhat.com  Wed Jun  6 09:44:14 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 6 Jun 2018 15:44:14 +0200
Subject: [python-committers] VSTS: how to rebuild a failing build?
Message-ID: <CA+3bQGHzy3AU_jQ_qEbRGKavQMfNMiqZP2gyF1gQwP6Og67B0A@mail.gmail.com>

Hi,

While we are discussing to make VSTS mandatory, I have a question: how
can I schedule a rebuild when VSTS failed (and the failure is
unrelated to my change)?

I'm logged in, but I don't see any action button on:
https://python.visualstudio.com/cpython/_build?buildId=6469

I guess that I lack some permissions. I clicked on at top right (on
"(VS)") -> "My profile" but I get an error :-) I cannot see my own
profile:

https://python.visualstudio.com/_details/profile/redirect
"Sorry, but Victor Stinner <victor.stinner at gmail.com> (Microsoft
account) is not authorized to access this page"

Note: the Windows-PR build failed because of an "internal error".
Steve Dower already passed the bug to the right people.
https://bugs.python.org/issue33782

Victor

From ncoghlan at gmail.com  Wed Jun  6 09:39:49 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 6 Jun 2018 23:39:49 +1000
Subject: [python-committers] Core Dev Sprints
In-Reply-To: <c78e2372-4f58-cc3d-4f90-34710b4d1b11@python.org>
References: <c78e2372-4f58-cc3d-4f90-34710b4d1b11@python.org>
Message-ID: <CADiSq7fEKQR4dKPNrMG7UD1zD460qrrj7avzMgOYBu9FYpG=zA@mail.gmail.com>

On 6 June 2018 at 08:53, Steve Dower <steve.dower at python.org> wrote:

> Finally, I am not the person you want designing the t-shirt for this
> event. If someone wants to step up and design/produce a t-shirt, now is the
> time to claim that responsibility. Otherwise we'll probably just try and
> off-load old Microsoft swag ;)
>

I was going to suggest you ask the Azure dev advocates to come up with
something involving their mascot Bit, and then I noticed the last entry on
https://github.com/ashleymcnamara/Developer-Advocate-Bit#find-me-on-twitter
:)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180606/30872a71/attachment.html>

From steve.dower at python.org  Wed Jun  6 10:13:12 2018
From: steve.dower at python.org (Steve Dower)
Date: Wed, 6 Jun 2018 07:13:12 -0700
Subject: [python-committers] VSTS: how to rebuild a failing build?
In-Reply-To: <CA+3bQGHzy3AU_jQ_qEbRGKavQMfNMiqZP2gyF1gQwP6Og67B0A@mail.gmail.com>
References: <CA+3bQGHzy3AU_jQ_qEbRGKavQMfNMiqZP2gyF1gQwP6Og67B0A@mail.gmail.com>
Message-ID: <mailman.12.1528294402.22131.python-committers@python.org>

Right now, close/reopen the PR is the easiest way. :( Even with login, it?s not so easy to restart a GitHub PR build because the integration isn?t fully there yet (I think you can only do it through the API and not the UI). I?m assured it?s coming ? this was top of my list of ?things we need? that I sent to the VSTS team.

Top-posted from my Windows 10 phone

From: Victor Stinner
Sent: Wednesday, June 6, 2018 6:45
To: python-committers
Subject: [python-committers] VSTS: how to rebuild a failing build?

Hi,

While we are discussing to make VSTS mandatory, I have a question: how
can I schedule a rebuild when VSTS failed (and the failure is
unrelated to my change)?

I'm logged in, but I don't see any action button on:
https://python.visualstudio.com/cpython/_build?buildId=6469

I guess that I lack some permissions. I clicked on at top right (on
"(VS)") -> "My profile" but I get an error :-) I cannot see my own
profile:

https://python.visualstudio.com/_details/profile/redirect
"Sorry, but Victor Stinner <victor.stinner at gmail.com> (Microsoft
account) is not authorized to access this page"

Note: the Windows-PR build failed because of an "internal error".
Steve Dower already passed the bug to the right people.
https://bugs.python.org/issue33782

Victor
_______________________________________________
python-committers mailing list
python-committers at python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180606/ee23056b/attachment.html>

From vstinner at redhat.com  Wed Jun  6 10:18:45 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 6 Jun 2018 16:18:45 +0200
Subject: [python-committers] VSTS: how to rebuild a failing build?
In-Reply-To: <5b17ec05.1c69fb81.5c2e.6710SMTPIN_ADDED_MISSING@mx.google.com>
References: <CA+3bQGHzy3AU_jQ_qEbRGKavQMfNMiqZP2gyF1gQwP6Og67B0A@mail.gmail.com>
 <5b17ec05.1c69fb81.5c2e.6710SMTPIN_ADDED_MISSING@mx.google.com>
Message-ID: <CA+3bQGEW3+YQb+Ejqty2HWgLgXJ1MTEO7hRqVvnMYXWU1ggByQ@mail.gmail.com>

> Right now, close/reopen the PR is the easiest way. :(

test_asyncio sometimes still fail randomly on Travis CI or AppVeyor:
https://bugs.python.org/issue33694

If I close/reopen the PR, I take the risk of getting a failure on a
differrent CI :-)

Victor

2018-06-06 16:13 GMT+02:00 Steve Dower <steve.dower at python.org>:
> Right now, close/reopen the PR is the easiest way. :( Even with login, it?s
> not so easy to restart a GitHub PR build because the integration isn?t fully
> there yet (I think you can only do it through the API and not the UI). I?m
> assured it?s coming ? this was top of my list of ?things we need? that I
> sent to the VSTS team.
>
>
>
> Top-posted from my Windows 10 phone
>
>
>
> From: Victor Stinner
> Sent: Wednesday, June 6, 2018 6:45
> To: python-committers
> Subject: [python-committers] VSTS: how to rebuild a failing build?
>
>
>
> Hi,
>
>
>
> While we are discussing to make VSTS mandatory, I have a question: how
>
> can I schedule a rebuild when VSTS failed (and the failure is
>
> unrelated to my change)?
>
>
>
> I'm logged in, but I don't see any action button on:
>
> https://python.visualstudio.com/cpython/_build?buildId=6469
>
>
>
> I guess that I lack some permissions. I clicked on at top right (on
>
> "(VS)") -> "My profile" but I get an error :-) I cannot see my own
>
> profile:
>
>
>
> https://python.visualstudio.com/_details/profile/redirect
>
> "Sorry, but Victor Stinner <victor.stinner at gmail.com> (Microsoft
>
> account) is not authorized to access this page"
>
>
>
> Note: the Windows-PR build failed because of an "internal error".
>
> Steve Dower already passed the bug to the right people.
>
> https://bugs.python.org/issue33782
>
>
>
> Victor
>
> _______________________________________________
>
> python-committers mailing list
>
> python-committers at python.org
>
> https://mail.python.org/mailman/listinfo/python-committers
>
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>

From steve.dower at python.org  Thu Jun  7 11:58:09 2018
From: steve.dower at python.org (Steve Dower)
Date: Thu, 7 Jun 2018 08:58:09 -0700
Subject: [python-committers] Core Dev Sprints
In-Reply-To: <c78e2372-4f58-cc3d-4f90-34710b4d1b11@python.org>
References: <c78e2372-4f58-cc3d-4f90-34710b4d1b11@python.org>
Message-ID: <5c7e8dd4-472a-3359-dead-c2599faefce5@python.org>

A few people have let me know that the invite email went to their junk 
folder (I was lazy and sent out one email to myself with everyone on 
BCC, so it's probably my fault).

If you were expecting an invite and haven't seen it, please check there. 
I'll send individual reminders before giving away places.

Also, if you haven't emailed python-dev or python-committers recently, I 
used the email associated with your bugs.python.org account, so you may 
also want to check there. None of the invites have bounced yet, so I 
assume they've all made it somewhere.

Cheers,
Steve

On 05Jun2018 1553, Steve Dower wrote:
> Hi all
> 
> Just a quick update to let everyone know that I've started sending out 
> invites for the sprints.
> 
> We have a limited number of *funded* places available, but room to 
> accommodate more people actually being there. So the way I'm approaching 
> this is by working down a somewhat arbitrarily-ordered list (with a bias 
> towards previous attendees, recent contributions, and newer core 
> developers) and sending out only as many invitations as we have funded 
> places.
> 
> As I hear that people either can't make it or don't need funding, I'll 
> invite the next person. So if you didn't receive an invite today, it 
> doesn't mean you aren't getting one. And if you _did_ receive an invite 
> today, the sooner you reply the more it'll help out everyone else.
> 
> Also, if you know already that you don't need PSF funding to attend but 
> you haven't got an invite yet, please reply to me off-list and let me 
> know. Our space is really only limited by "how many people in our large 
> room is too many" (the fire marshal says about 120 people...), so you 
> won't miss out. But you are able to skip the queue, as it were.
> 
> Finally, I am not the person you want designing the t-shirt for this 
> event. If someone wants to step up and design/produce a t-shirt, now is 
> the time to claim that responsibility. Otherwise we'll probably just try 
> and off-load old Microsoft swag ;)
> 
> Cheers,
> Steve

From vstinner at redhat.com  Sun Jun 10 07:31:34 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sun, 10 Jun 2018 12:31:34 +0100
Subject: [python-committers] Turning off AppVeyor as required
In-Reply-To: <CA+3bQGGqcMw-Mj30LZ9gbXnU+Fu5hykJ3KpgnRGZwTFdO8s2yA@mail.gmail.com>
References: <CAP1=2W4zcwpg2Jvm4SpVo4jTRjZ2UrcZNvWfWy-+Oxc63TeC7g@mail.gmail.com>
 <CA+3bQGGqcMw-Mj30LZ9gbXnU+Fu5hykJ3KpgnRGZwTFdO8s2yA@mail.gmail.com>
Message-ID: <CA+3bQGErcLcbYjAv7+8RBv16Po6x+k08tK-Z0nZeZP5xdpi9+g@mail.gmail.com>

Brett Cannon just made AppVeyor required again on 2.7, 3.6, 3.7 and master ;-)

Victor

2018-06-04 21:38 GMT+01:00 Victor Stinner <vstinner at redhat.com>:
> I have very good news from AppVeyor:
>
> * AppVeyor runs again jobs on pull requests: it's back!
> * Issue with quotas: it was a disk issue, it was on their side and
> it's now fixed.
> * AppVeyor donate us additional parallel job to the python account!
>
> Moreover:
>
> * They proposed us to extend the timeout to 90 minuts. Hopefully, a
> full build (download + compile + run tests) takes usually less than 15
> min, so it's fine.
> * They explained me how to disable AppVeyor on branches to only run
> tests on pull requests. "Do not build feature branches with open Pull
> Requests in UI (skip_branch_with_pr: true if you use YAML)." seems the
> safest option. Another option is: "disable Pushes event in GitHub
> Webhook settings" but I don't undestand if it only impacts AppVeyor or
> all our hooks.
>
> Thank you very much AppVeyor! See my support issue for the details:
>
> http://help.appveyor.com/discussions/problems/14532-cpython-exceeded-allowed-resource-quotas-what-are-these-quotas-can-them-be-increased
>
> Victor
>
> 2018-06-04 17:02 GMT+02:00 Brett Cannon <brett at python.org>:
>> Victor noticed that AppVeyor stopped building about 19 hours ago, leading to
>> it blocking all open PRs. I have gone ahead and switched off requiring
>> AppVeyor for now, so please pay attention to at least the Windows VSTS
>> status check to make sure you're not breaking Windows by accident.
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>

From taleinat at gmail.com  Mon Jun 11 01:38:04 2018
From: taleinat at gmail.com (Tal Einat)
Date: Mon, 11 Jun 2018 08:38:04 +0300
Subject: [python-committers] b.p.o. status and resolution permissions
Message-ID: <CALWZvp4rerH7vDEoUjt1GCAkSv-RdHLXVZ6W=2wgP0p3LESo7A@mail.gmail.com>

Hi,

I'm a (somewhat) new core-dev and have begun working on various issues.

I don't have permission to change issue status and resolution on b.p.o. It
seems at this point that is holding things back and making more work for
others. I will be extra careful and only change those when I'm very sure it
is appropriate.

Can the necessary permission bits be flipped?

- Tal Einat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180611/3369f6d6/attachment.html>

From nad at python.org  Mon Jun 11 01:56:33 2018
From: nad at python.org (Ned Deily)
Date: Mon, 11 Jun 2018 01:56:33 -0400
Subject: [python-committers] b.p.o. status and resolution permissions
In-Reply-To: <CALWZvp4rerH7vDEoUjt1GCAkSv-RdHLXVZ6W=2wgP0p3LESo7A@mail.gmail.com>
References: <CALWZvp4rerH7vDEoUjt1GCAkSv-RdHLXVZ6W=2wgP0p3LESo7A@mail.gmail.com>
Message-ID: <49FF8E25-DC2D-45E1-812D-1533C0E81A24@python.org>

On Jun 11, 2018, at 01:38, Tal Einat <taleinat at gmail.com> wrote:
> I'm a (somewhat) new core-dev and have begun working on various issues.
> 
> I don't have permission to change issue status and resolution on b.p.o. It seems at this point that is holding things back and making more work for others. I will be extra careful and only change those when I'm very sure it is appropriate.
> 
> Can the necessary permission bits be flipped?

You should be good to go now.  Welcome to the tracker!

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Mon Jun 11 06:23:14 2018
From: nad at python.org (Ned Deily)
Date: Mon, 11 Jun 2018 06:23:14 -0400
Subject: [python-committers] 3.7.0rc1 and 3.6.6rc happening later today!
Message-ID: <6AFB2CAC-BFDA-45C5-BEF2-B2954E63DB36@python.org>

Short and sweet: thanks to a *lot* of work by a lot of people, we appear
to be about ready to finally tag and manufacture the 3.7.0 release
candidate!

At the moment, we have no "release blocker" or "deferred blocker" issues
open for 3.7 - a first! We also now have 21 out of 22 3.7 "production"
buildbots consistently green or occasionally pink (meaning successful
test retry) - also quite an accomplishment. (Only the 3.7 AIX PPC64
buildbot remains red but, since we really only support AIX on a "best
effort" basis, we are not going to further delay 3.7.0 for it.) We have
also had to make some tough decisions and defer some features to 3.8 and
a few more complex bug resolutions to 2.7.1 or later. And releasing the
"bonus beta", 3.7.0b5, resulted in some good feedback and squashing a few
more issues.

As you may recall, the most recently updated schedule calls for both
3.7.0rc1 and 3.6.6rc1 to be produced today, 2018-06-11, with the finals
coming about two weeks later on 2018-06-27. I plan to start on 3.6.6rc1
in about 12 hours (around 22:00 UTC) with 3.7.0rc1 to follow soon
thereafter. Feel free to use the remaining time to merge any last-minute
documentation updates or minor bug fixes - but please do not break
anything! When in doubt, ask. (I will be off-line for the next 8 hours or
so.)

After 3.7.0rc1 cutoff, new 3.7 merges will appear in 3.7.1, which should
appear sometime next month (by the end of 2018-07). Likewise, new 3.6
merges will next appear in 3.6.7rc1, by the end of 2018-09. Please
continue to exercise diligence when deciding whether a change is
appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it
were already released and in maintenance mode. Please also pay attention
to CI test failures and buildbot test failures and see if you can help
resolve them. As always, if you think you may have found a critical
problem at any time in either release candidate, please open (or reuse)
an issue on bugs.python.org and mark it as "release blocker" priority.

3.7.0: here we come, thanks to you!

--Ned

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Tue Jun 12 04:10:38 2018
From: nad at python.org (Ned Deily)
Date: Tue, 12 Jun 2018 04:10:38 -0400
Subject: [python-committers] 3.7.0rc1 and 3.6.6rc1 now tagged - on to final!
Message-ID: <92F63555-A1EC-4AD6-9AC5-4A1A0A3EBC7E@python.org>

An update: 3.7.0rc1 and 3.6.6rc1 are now tagged and we now move on to the
final stages for 3.7.0 and for 3.6.6. The source code has been shipped to
our factory (in a tariff-free zone!) where the elves will produce the
final bits for the release. They promise to be done soon so stay tuned
for the release announcements later today.

In the meantime, the 3.7 and 3.6 branches in the cpython repo are open
for merges. As of the rc1 cutoffs (tags v3.7.0rc1 and v3.6.6rc1 in the
cpython repo), expect merges to 3.7 to appear in 3.7.1 and merges to 3.6
to appear in 3.6.7. Please continue to treat the 3.7 branch as if it were
already released and in maintenance mode. Please continue to pay
attention to CI test failures and buildbot test failures and see if you
can help resolve them. If you find something that may affect either final
release, please make sure to open a new issue on bugs.python.org, or
update an existing issue, and set the priority to "release blocker". As
always, improving the documentation never ceases so keep those updates
coming in. Prior to 3.7.0 final and 3.6.6 final, I will review doc
changes that have been merged and consider cherry-picking them into the
release materials. By the way, don't be fooled: if you build Python from
the 3.7 branch at the moment, the version will be "3.7.0rc1+" but changes
merged will be in 3.7.1; similarly for 3.6.

The clock is now ticking: 15 days until the final releases. Please do
what you can to encourage exposure and testing by ourselves and our
downstream users.

Once again, I want to thank everyone who has been involved so far in
helping us through the 3.7 endgame and who have given up their
personal time to work on making Python better. I remain deeply grateful.

--Ned

Upcoming dates:
- 2018-06-27 3.7.0 final !!! and 3.6.6 final !!
- 2018-07-xx 3.7.1
- 2018-09-xx 3.6.7


--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Tue Jun 12 16:29:38 2018
From: nad at python.org (Ned Deily)
Date: Tue, 12 Jun 2018 16:29:38 -0400
Subject: [python-committers] [RELEASE] Python 3.7.0rc1 and 3.6.6rc1 are now
 available
Message-ID: <18BD5CA7-EB42-477F-9D14-7EE78CBEB5C2@python.org>

Python 3.7.0rc1 and 3.6.6rc1 are now available. 3.7.0rc1 is the final
planned release preview of Python 3.7, the next feature release of
Python. 3.6.6rc1 is the the release preview of the next maintenance
release of Python 3.6, the current release of Python. Assuming no
critical problems are found prior to *2018-06-27*, the scheduled
release dates for 3.7.0 and 3.6.6, no code changes are planned
between these release candidates and the final releases. These
release candidates are intended to give you the opportunity to test
the new features and bug fixes in 3.7.0 and 3.6.6 and to prepare your
projects to support them. We strongly encourage you to test your
projects and report issues found to bugs.python.org as soon as
possible. Please keep in mind that these are preview releases and,
thus, their use is not recommended for production environments.
Attention macOS users: there is now a new installer variant for macOS
10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant
will become the default version when 3.7.0 releases. Check it out!

You can find these releases and more information here:
    https://www.python.org/downloads/release/python-370rc1/
    https://www.python.org/downloads/release/python-366rc1/

--
  Ned Deily
  nad at python.org -- []


From vstinner at redhat.com  Wed Jun 13 12:16:13 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 13 Jun 2018 18:16:13 +0200
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as core
 developer
Message-ID: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>

Hi,

I propose to promote Pablo Salingo Salgado as a core developer and so
open a vote during one week. If there is no strong opposition, I will
promote him but also continue to mentor him for a least one month.

Pablo is contributing frequently to Python since almost one year. He
added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to
Python 3.8. I am now waiting for his os.copy_file_range() function!
(Others are working on it.)
https://bugs.python.org/issue26826

I am mentoring Pablo Salingo Salgado since January. I am watching his
hard work since last September. He made many non trivial and useful
contributions to Python.

I think that he understands well how Python is developed, is
respectful, try to find answers alone before asking, and is eager to
learn. In case of doubt, he ask others before doing something, like
closing an issue. I trust that Pablo will respect opinions of others,
like not merging a PR if someone disagree.

Pablo's merged PR:
https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+

He got 22 commits merged into master between September 2017 and June 2018.

If Pablo is promoted as a core developer, I propose to continue to be
his mentor for at least one month, and ask him before merging any PR.

Note: Pablo already has the bug triage permission for 5 months:
https://mail.python.org/pipermail/python-committers/2018-January/005133.html

Victor

From tjreedy at udel.edu  Wed Jun 13 12:43:29 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 13 Jun 2018 12:43:29 -0400
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
Message-ID: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>

On 6/13/2018 12:16 PM, Victor Stinner wrote:
> Hi,
> 
> I propose to promote Pablo Salingo Salgado as a core developer and so
> open a vote during one week. If there is no strong opposition, I will
> promote him but also continue to mentor him for a least one month.
> 
> Pablo is contributing frequently to Python since almost one year. He
> added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to
> Python 3.8. I am now waiting for his os.copy_file_range() function!
> (Others are working on it.)
> https://bugs.python.org/issue26826
> 
> I am mentoring Pablo Salingo Salgado since January. I am watching his
> hard work since last September. He made many non trivial and useful
> contributions to Python.
> 
> I think that he understands well how Python is developed, is
> respectful, try to find answers alone before asking, and is eager to
> learn. In case of doubt, he ask others before doing something, like
> closing an issue. I trust that Pablo will respect opinions of others,
> like not merging a PR if someone disagree.
> 
> Pablo's merged PR:
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+

This includes closed without merging.

> He got 22 commits merged into master between September 2017 and June 2018.

https://github.com/python/cpython/pulls?page=2&q=is%3Amerged+is%3Apr+author%3Apablogsal&utf8=%E2%9C%93

shows 27 merged, 1 a backport.  Merges were by several different people.
+1

> If Pablo is promoted as a core developer, I propose to continue to be
> his mentor for at least one month, and ask him before merging any PR
> Note: Pablo already has the bug triage permission for 5 months:
> https://mail.python.org/pipermail/python-committers/2018-January/005133.html


From storchaka at gmail.com  Wed Jun 13 15:38:15 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 13 Jun 2018 22:38:15 +0300
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
Message-ID: <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>

13.06.18 19:43, Terry Reedy ????:
> On 6/13/2018 12:16 PM, Victor Stinner wrote:
>> I propose to promote Pablo Salingo Salgado as a core developer and so
>> open a vote during one week. If there is no strong opposition, I will
>> promote him but also continue to mentor him for a least one month.
>>
>> Pablo is contributing frequently to Python since almost one year. He
>> added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to
>> Python 3.8. I am now waiting for his os.copy_file_range() function! x
>> (Others are working on it.)
>> https://bugs.python.org/issue26826
>>
>> I am mentoring Pablo Salingo Salgado since January. I am watching his
>> hard work since last September. He made many non trivial and useful
>> contributions to Python.
>>
>> I think that he understands well how Python is developed, is
>> respectful, try to find answers alone before asking, and is eager to
>> learn. In case of doubt, he ask others before doing something, like
>> closing an issue. I trust that Pablo will respect opinions of others,
>> like not merging a PR if someone disagree.
>>
>> Pablo's merged PR:
>> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+ 
>>
>
> This includes closed without merging.

And reverted PRs. Adding ensure_disabled() (bpo-31356) was reverted 
because the implementation caused crash and core developers have doubts 
about usefulness of this feature at all. Adding posix_spawn() 
(bpo-20104) was reverted in 3.7 because it was incomplete and had many 
bugs. It was left in 3.8, and the work of completing and fixing it in 
process. PR 4003 has long review history, the final merged version is 
very different from the initial one. Many of other PRs are documentation 
fixes.

I think Pablo will be good core developer and agree with the description 
given by Victor. But it seems that he still needs to learn something 
about what changes are good for Python.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180613/99a24b58/attachment.html>

From vstinner at redhat.com  Wed Jun 13 15:57:07 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 13 Jun 2018 21:57:07 +0200
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
Message-ID: <CA+3bQGEK419MkstUSPZ9O8xPmqV-fz8SV5KHWm2pXvhMYRcsqA@mail.gmail.com>

2018-06-13 18:43 GMT+02:00 Terry Reedy <tjreedy at udel.edu>:
>> Pablo's merged PR:
>>
>> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+
>
> This includes closed without merging.
>
>> He got 22 commits merged into master between September 2017 and June 2018.
>
> https://github.com/python/cpython/pulls?page=2&q=is%3Amerged+is%3Apr+author%3Apablogsal&utf8=%E2%9C%93
>
> shows 27 merged, 1 a backport.  Merges were by several different people.
> +1

I computed the number of patches merged into master using:

$ git log master --author=Pablogsal at gmail.com|grep ^commit -c
22

Oh sorry, I posted the wrong link. I wanted to post this link:
https://github.com/python/cpython/commits?author=pablogsal

I counted manually and I see again 22 changes.

Victor

From vstinner at redhat.com  Wed Jun 13 16:46:18 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 13 Jun 2018 22:46:18 +0200
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
Message-ID: <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>

2018-06-13 21:38 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
>> Pablo's merged PR:
>> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+
>
> This includes closed without merging.

(sorry again, bad link.)


> And reverted PRs. Adding ensure_disabled() (bpo-31356) was reverted because
> the implementation caused crash and core developers have doubts about
> usefulness of this feature at all.

Hum, let me see:
https://bugs.python.org/issue31356#msg301407

The feature has been proposed by Raymond Hettinger and approved ("+1")
by Nick Coghlan. Pablo's PR has been merged by Raymond.

It's not like Pablo proposed the idea himself and force to get this
feature merged. Pablo just implemented an idea proposed by two other
core developers.

It happens that core developers disagree each others ;-) The feature
has been quickly removed, it's not a big deal.


> Adding posix_spawn() (bpo-20104) was
> reverted in 3.7 because it was incomplete and had many bugs. It was left in
> 3.8, and the work of completing and fixing it in process.

(a) Two days after Pablo proposed his PR, he wrote an email to
python-dev to get the widest audience to design posix_spawn() API:
https://mail.python.org/pipermail/python-dev/2018-January/151661.html

Gregory P. Smith merged Pablo's PR, after one month of review.

IMHO Pablo did the best to get the correct API and a good implementation.


(b) After the PR has been approved and merged, Serhiy noticed that the
Python function doesn't expose one posix_spawn() feature.

During Pycon US, we discussed what do to with posix_spawn() before the
Python 3.7 release: urge to push a change, or revert. I proposed to
Pablo to remove the feature from 3.7, get more time to stabilize the
API and the implementation in master. He was fine with that.

He could complain and ask to keep the feature (to get it released as
soon as possible), but he didn't.

I don't see anything wrong here. It's not uncommon that a newly merged
feature is still discussed, and I don't see anything wrong with
Pablo's behaviour here. I don't see how we could prevent such further
discussions on posix_spawn(). At least, I don't see how Pablo could
prevent these issues.


> PR 4003 has long  review history, the final merged version is very different from the initial
> one.

"bpo-31786: Make select.poll.poll block if ms < 0 for every value of ms"
https://github.com/python/cpython/pull/4003

Oh, I recall that one, I recall that *I* was super pedantic :-)

You (Serhiy) asked to fix select.poll.poll() for negative timeout.
This is exactly what Pablo did. His PR was fine on that aspect.

Then I started to complain and ask to use my private _PyTime API. I
also asked to implement a new rounding mode for _PyTime: a complex
task, because it requires to modify a lot of files, write new tests,
etc. This C code is not well documented.

Then I asked to not only modify select.poll, but many other functions.

The final PR is very different because I requested to modify much more
files and fix many more functions.

At the end, I really like the final commit:
https://github.com/python/cpython/commit/2c15b29aea5d6b9c61aa42d2c24a07ff1edb4b46

It adds a new rounding mode (_PyTime_ROUND_UP), write a non-trivial
function test for negative timeout, has a good NEWS entry, etc.

Pablo showed that he is able to implement large change and fix all
cases, not a single case. IMHO it's a good example, rather than a bad
example :-)


> Many of other PRs are documentation fixes.

Is it an issue?


> I think Pablo will be good core developer and agree with the description
> given by Victor. But it seems that he still needs to learn something about
> what changes are good for Python.

Ok, I account your -1 vote.


But I disagree you with :-) Pablo worked on complex changes, so I'm
not surprised that his changes required a lot of discussion, and that
there are some hiccups like posix_spawn() issues. By the way,
posix_spawn() is one of the most complex C function that I know...
Compare its API to dup() API: well, dup() is simpler :-) But
posix_spawn() seems efficient and very useful.

Again, I don't see anything wrong with Pablo's behaviour or the
quality of his work. I understand that you want more reviewers on
posixmodule.c changes, and there is where I expect that Pablo will
help :-) In private, I told Pablo that I consider that the main
difference between a core developer and a contributor is that core
developers are expected to spend more time on reviews and mentoring.

Pablo proved its steady involvment in Python for almost one year with
multiple significant contributions (new os functions). IMHO you are
pushing the bar too high.

Victor

From berker.peksag at gmail.com  Wed Jun 13 18:26:52 2018
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Thu, 14 Jun 2018 01:26:52 +0300
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
Message-ID: <CAF4280L+Aht5HH1501gifaQHX8HnnXJUj4ZwsV6pYvkBfzJafg@mail.gmail.com>

On Wed, Jun 13, 2018 at 10:38 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> I think Pablo will be good core developer and agree with the description
> given by Victor. But it seems that he still needs to learn something about
> what changes are good for Python.

I agree with Serhiy. Count me -1 for now.

I don't care about total number of commits to be honest. It's not so
hard to get 50 PRs merged into master in a month or so. Writing high
quality code is not the only requirement to become a core developer.
IMO, being active on bugs.p.o [1] and reviewing pull requests on
GitHub [2] are more important than writing code or documentation.

--Berker

[1] According to bpo, Pablo has been active in 38 issues:
https://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=pablogsal&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&status=&%40columns=status&resolution=&nosy_count=&message_count=&%40group=&%40pagesize=50&%40startwith=0&%40sortdir=on&%40queryname=&%40old-queryname=&%40action=search

[2] Looking at Pablo's GitHub profile (from October 2017 to June 2018)
most of Pablo's review comments seems to be made in their own PRs.
I've found two non-core developer PRs reviewed by Pablo:
https://github.com/python/cpython/pull/6984 and
https://github.com/python/cpython/pull/6481

From willingc at gmail.com  Wed Jun 13 19:03:47 2018
From: willingc at gmail.com (Carol Willing)
Date: Wed, 13 Jun 2018 16:03:47 -0700
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
Message-ID: <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>

+1 With Victor's mentoring (1 or 2 months), I believe that it is reasonable to promote Pablo to a core developer either now or after 3 months of coaching.

I would also like to see Cheryl Sabella who has been very active on the bug tracker to also be promoted to a core developer as well as Emily Morehouse who has been at the Language Summit for several years.

I'm happy to trust Victor's perspective as well as Pablo being respectful of the merge process.

FWIW, I also believe that triaging issues, writing documentation, and contributing code are all valuable to the success of CPython. Without issue triage and quality documentation being valued, the users and contributors suffer a lack of information and efficiency as well as demotivating potential developers.


> On Jun 13, 2018, at 1:46 PM, Victor Stinner <vstinner at redhat.com <mailto:vstinner at redhat.com>> wrote:
> 
> Pablo proved its steady involvment in Python for almost one year with
> multiple significant contributions (new os functions). IMHO you are
> pushing the bar too high.

> I think Pablo will be good core developer and agree with the description given by Victor.But it seems that he still needs to learn something about what changes are good for Python
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180613/659fe385/attachment.html>

From tjreedy at udel.edu  Wed Jun 13 22:30:21 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 13 Jun 2018 22:30:21 -0400
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
 <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
Message-ID: <d9b83569-8cf1-fc3f-7158-b4354e1e32b8@udel.edu>

On 6/13/2018 7:03 PM, Carol Willing wrote:
> +1 With Victor's mentoring (1 or 2 months), I believe that it is 
> reasonable to promote Pablo to a core developer either now or after 3 
> months of coaching.
> 
> I would also like to see Cheryl Sabella who has been very active on the 
> bug tracker to also be promoted to a core developer.

A bit off topic, but I would too, as she has been extremely helpful with 
IDLE.  We have discussed it privately and I offered to sponsor her here 
whenever she wants me to.  At the moment, she is happy doing what she 
does with the time she has.

Terry Jan Reedy


From willingc at gmail.com  Thu Jun 14 00:04:32 2018
From: willingc at gmail.com (Carol Willing)
Date: Wed, 13 Jun 2018 21:04:32 -0700
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <d9b83569-8cf1-fc3f-7158-b4354e1e32b8@udel.edu>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
 <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
 <d9b83569-8cf1-fc3f-7158-b4354e1e32b8@udel.edu>
Message-ID: <8DE66BB4-D4F9-4D43-BA29-BB0FCE83A37F@gmail.com>



> On Jun 13, 2018, at 7:30 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> On 6/13/2018 7:03 PM, Carol Willing wrote:
>> +1 With Victor's mentoring (1 or 2 months), I believe that it is reasonable to promote Pablo to a core developer either now or after 3 months of coaching.
>> I would also like to see Cheryl Sabella who has been very active on the bug tracker to also be promoted to a core developer.
> 
> A bit off topic, but I would too, as she has been extremely helpful with IDLE.  We have discussed it privately and I offered to sponsor her here whenever she wants me to.  At the moment, she is happy doing what she does with the time she has.
> 
> Terry Jan Reedy
> 

Thanks Terry for discussing with her and mentoring her on IDLE :-)


> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


From vstinner at redhat.com  Thu Jun 14 04:46:53 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 14 Jun 2018 10:46:53 +0200
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CAF4280L+Aht5HH1501gifaQHX8HnnXJUj4ZwsV6pYvkBfzJafg@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CAF4280L+Aht5HH1501gifaQHX8HnnXJUj4ZwsV6pYvkBfzJafg@mail.gmail.com>
Message-ID: <CA+3bQGGCvuVg5oPFjOnNmYv1TxgbDN6A80y0rZkfpsTDZVAbeg@mail.gmail.com>

2018-06-14 0:26 GMT+02:00 Berker Peksa? <berker.peksag at gmail.com>:
> I don't care about total number of commits to be honest. It's not so
> hard to get 50 PRs merged into master in a month or so.

Wait, what? No developer got more than 50 commits merged into master
in less than one month.

Stats between May, 1st and today (one month and a half, longer than
one month), top 5
---
39 Serhiy Storchaka <storchaka at gmail.com>
31 Victor Stinner <vstinner at redhat.com>
24 Yury Selivanov <yury at magic.io>
18 Andr?s Delfino <adelfino at gmail.com>
16 Ned Deily <nad at python.org>
---

Statistics on the master branch between September 1st, 2017 and today,
developers with at least 20 commits:
---
221 Serhiy Storchaka
221 Victor Stinner
89 Yury Selivanov
67 Ned Deily
60 Benjamin Peterson
56 Terry Jan Reedy
51 Christian Heimes
41 Eric V. Smith
41 INADA Naoki
37 Antoine Pitrou
36 Raymond Hettinger
35 Steve Dower
34 Cheryl Sabella
34 Andrew Svetlov
31 Oren Milman
29 Barry Warsaw
26 xdegaye
24 Andr?s Delfino
22 Eric Snow
21 Pablo Galindo
20 Berker Peksag
---

But if you ignore core developers, here is the top 6 most active contributors:
---
34 Cheryl Sabella
31 Oren Milman
24 Andr?s Delfino
21 Pablo Galindo
18 Zackery Spytz
9 Paul Ganssle
---

I let you look at each commit to estimate how much time each
contributor has spent on Python.

Note: Oh, it seems like Pablo got one commit as a different name but
with same email ("Author: Dargor <Pablogsal at gmail.com>"). The correct
number for Pablo is 22.

Note2: Pablo got 2 more commits merged into master (22) than Berker (20) ;-)


> [1] According to bpo, Pablo has been active in 38 issues:

It seems that he is active, if not very active, on the bug tracker,
no? But how can I compare this number to other core developers or
other contributors?


> Writing high quality code is not the only requirement to become a core developer.
> IMO, being active on bugs.p.o [1] and reviewing pull requests on
> GitHub [2] are more important than writing code or documentation.

I'm not sure that it works in this direction. I expect that once a
developer is promoted as a core dev, they become more active on
reviews and bug triage. It's my (personal) definition of the
additional responsibilities of a core developer. I don't see why a
contributor will spend time on reviews and bug triage before becoming
a core. Writing pull requests is a good way to learn how to produce
good reviews.

There are 90 core developers in the GitHub team: how many of them are
regularly doing reviews and bug triage? Don't expect that a new core
developer will be at least as active, if not more, than existing core
developers. I'm happy if I review 5 pull requests per week. It takes a
lot of time to review properly a PR.

As I wrote to Serhiy, IMHO you are putting the bar too high.

Our role is to mentor and guide contributors to make them feel part of
a team and feel useful by recognizing the value of their work.

Please remind that they are very few contributors with available free
time and ready to be invested in the long term.

In my experience, naturally, when a contributor is promoted, they
become more active in different areas of Python: bug tracker, mailing
list, devguide, etc.


My script to compute stats:
---
import collections
import subprocess
proc = subprocess.run(['git', 'log', '--after=2017-09-01', 'master'],
                      stdout=subprocess.PIPE,
                      universal_newlines=True)
authors = collections.Counter()
for line in proc.stdout.splitlines():
    if line.startswith('Author: '):
        line = line[8:]
        name = line.split(' <')[0]
        authors[name] += 1
for name, commits in authors.most_common():
    if commits < 5:
        break
    print(commits, name)
---

Victor

From berker.peksag at gmail.com  Thu Jun 14 07:40:35 2018
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Thu, 14 Jun 2018 14:40:35 +0300
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CA+3bQGGCvuVg5oPFjOnNmYv1TxgbDN6A80y0rZkfpsTDZVAbeg@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CAF4280L+Aht5HH1501gifaQHX8HnnXJUj4ZwsV6pYvkBfzJafg@mail.gmail.com>
 <CA+3bQGGCvuVg5oPFjOnNmYv1TxgbDN6A80y0rZkfpsTDZVAbeg@mail.gmail.com>
Message-ID: <CAF4280KDHLJDL_x2gY75uMOmpCAzegOEyBXQFc74jt4PD3zYkA@mail.gmail.com>

On Thu, Jun 14, 2018 at 11:46 AM, Victor Stinner <vstinner at redhat.com> wrote:
> 2018-06-14 0:26 GMT+02:00 Berker Peksa? <berker.peksag at gmail.com>:
>> I don't care about total number of commits to be honest. It's not so
>> hard to get 50 PRs merged into master in a month or so.
>
> Wait, what? No developer got more than 50 commits merged into master
> in less than one month.

That was just a hypothetical number to explain that only looking at
some numbers can be misleading... But if you really need "real"
numbers, here's a recent example: 16 commits in less than a month:
https://github.com/python/cpython/commits?author=andresdelfino

> Note2: Pablo got 2 more commits merged into master (22) than Berker (20) ;-)

I don't like what you're hinting, but I will give you the benefit of
the doubt. I will just point out that I've reviewed 89 pull requests
since last September. It seems like we have very different
understanding of the differences between contributors and core
developers/maintainers.

>> [1] According to bpo, Pablo has been active in 38 issues:
>
> It seems that he is active, if not very active, on the bug tracker,
> no? But how can I compare this number to other core developers or
> other contributors?

Since their name already mentioned in the thread, you can take a look
at Cherly Sabella's activity on the tracker.

> As I wrote to Serhiy, IMHO you are putting the bar too high.

This isn't about my or someone else's high standards. We keep saying
we need more triagers and reviewers, and we keep promoting people who
didn't do any issue triaging and code review. It's not fair to
contributors who have spent so much time working on these areas.

> Please remind that they are very few contributors with available free
> time and ready to be invested in the long term.

Correct, that's basically the difference between a contributor and a
core developer/maintainer. If they don't have time or motivation to
invest in a project long term, it's perfectly fine. They don't have to
be a core developer to be a valuable member of the community.

From vstinner at redhat.com  Thu Jun 14 08:02:28 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 14 Jun 2018 14:02:28 +0200
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
Message-ID: <CA+3bQGErGm6kim5N9gC3BxJUL46UGB=7dbuZ5nAEt-dzUdFT3Q@mail.gmail.com>

Oh, I forgot to mention that Pablo is already helping me on triagging
buildbot failures since 1 month.See my email to python-dev for the
context:

"[Python-Dev] How to watch buildbots?"
https://mail.python.org/pipermail/python-dev/2018-May/153754.html

You can see his emails on the buildbot-status mailing list:
https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/

Victor

2018-06-13 18:16 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> Hi,
>
> I propose to promote Pablo Salingo Salgado as a core developer and so
> open a vote during one week. If there is no strong opposition, I will
> promote him but also continue to mentor him for a least one month.
>
> Pablo is contributing frequently to Python since almost one year. He
> added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to
> Python 3.8. I am now waiting for his os.copy_file_range() function!
> (Others are working on it.)
> https://bugs.python.org/issue26826
>
> I am mentoring Pablo Salingo Salgado since January. I am watching his
> hard work since last September. He made many non trivial and useful
> contributions to Python.
>
> I think that he understands well how Python is developed, is
> respectful, try to find answers alone before asking, and is eager to
> learn. In case of doubt, he ask others before doing something, like
> closing an issue. I trust that Pablo will respect opinions of others,
> like not merging a PR if someone disagree.
>
> Pablo's merged PR:
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+
>
> He got 22 commits merged into master between September 2017 and June 2018.
>
> If Pablo is promoted as a core developer, I propose to continue to be
> his mentor for at least one month, and ask him before merging any PR.
>
> Note: Pablo already has the bug triage permission for 5 months:
> https://mail.python.org/pipermail/python-committers/2018-January/005133.html
>
> Victor

From greg at krypto.org  Thu Jun 14 13:25:29 2018
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 14 Jun 2018 10:25:29 -0700
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CA+3bQGErGm6kim5N9gC3BxJUL46UGB=7dbuZ5nAEt-dzUdFT3Q@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <CA+3bQGErGm6kim5N9gC3BxJUL46UGB=7dbuZ5nAEt-dzUdFT3Q@mail.gmail.com>
Message-ID: <CAGE7PNLO3wJW0AOwghvksJH7H3S4MJD0FveAhLiETV2_j1N+VQ@mail.gmail.com>

Quick response:

+0.5

My first reaction was "really?" given the amount of iteration required due
to lack of CPython extension module API experience demonstrated in the
os.posix_spawn PRs.  (I am not surprised to see Serhiy's negative
reaction)  But Pablo shows drive and desire to do good things and an
ability to eventually do it even if there are learning bumps along the
way.  With mentoring and PR reviews (which I'm assuming Victor is signing
up for) I believe Pablo would make a fine core developer.

So +0.5 from me.  I wouldn't give Pablo free reign to make changes yet -
mentoring required - but that is exactly how most of us start off while we
learn.  I know I started that way.

-gps




On Thu, Jun 14, 2018 at 5:06 AM Victor Stinner <vstinner at redhat.com> wrote:

> Oh, I forgot to mention that Pablo is already helping me on triagging
> buildbot failures since 1 month.See my email to python-dev for the
> context:
>
> "[Python-Dev] How to watch buildbots?"
> https://mail.python.org/pipermail/python-dev/2018-May/153754.html
>
> You can see his emails on the buildbot-status mailing list:
> https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/
>
> Victor
>
> 2018-06-13 18:16 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> > Hi,
> >
> > I propose to promote Pablo Salingo Salgado as a core developer and so
> > open a vote during one week. If there is no strong opposition, I will
> > promote him but also continue to mentor him for a least one month.
> >
> > Pablo is contributing frequently to Python since almost one year. He
> > added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to
> > Python 3.8. I am now waiting for his os.copy_file_range() function!
> > (Others are working on it.)
> > https://bugs.python.org/issue26826
> >
> > I am mentoring Pablo Salingo Salgado since January. I am watching his
> > hard work since last September. He made many non trivial and useful
> > contributions to Python.
> >
> > I think that he understands well how Python is developed, is
> > respectful, try to find answers alone before asking, and is eager to
> > learn. In case of doubt, he ask others before doing something, like
> > closing an issue. I trust that Pablo will respect opinions of others,
> > like not merging a PR if someone disagree.
> >
> > Pablo's merged PR:
> >
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+
> >
> > He got 22 commits merged into master between September 2017 and June
> 2018.
> >
> > If Pablo is promoted as a core developer, I propose to continue to be
> > his mentor for at least one month, and ask him before merging any PR.
> >
> > Note: Pablo already has the bug triage permission for 5 months:
> >
> https://mail.python.org/pipermail/python-committers/2018-January/005133.html
> >
> > Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180614/943d1edb/attachment.html>

From brett at python.org  Thu Jun 14 14:18:28 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 14 Jun 2018 11:18:28 -0700
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
 <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
Message-ID: <CAP1=2W5RYM2FQUdV2JZ8A6VZShEfm9f=J-WGdiHqrVJ9x3Enhg@mail.gmail.com>

On Wed, 13 Jun 2018 at 16:11 Carol Willing <willingc at gmail.com> wrote:

> +1 With Victor's mentoring (1 or 2 months), I believe that it is
> reasonable to promote Pablo to a core developer either now or after 3
> months of coaching.
>
> I would also like to see Cheryl Sabella who has been very active on the
> bug tracker to also be promoted to a core developer as well as Emily
> Morehouse who has been at the Language Summit for several years.
>

In both cases I think we just need someone to start a separate thread
asking to have them be promoted along with the usual promise to mentor them
for a month or so.

-Brett


>
> I'm happy to trust Victor's perspective as well as Pablo being respectful
> of the merge process.
>
> FWIW, I also believe that triaging issues, writing documentation, and
> contributing code are all valuable to the success of CPython. Without issue
> triage and quality documentation being valued, the users and contributors
> suffer a lack of information and efficiency as well as demotivating
> potential developers.
>
>
> On Jun 13, 2018, at 1:46 PM, Victor Stinner <vstinner at redhat.com> wrote:
>
> Pablo proved its steady involvment in Python for almost one year with
> multiple significant contributions (new os functions). IMHO you are
> pushing the bar too high.
>
>
> > I think Pablo will be good core developer and agree with the
> description given by Victor.But it seems that he still needs to learn
> something about what changes are good for Python
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180614/91c4d5e8/attachment.html>

From ericsnowcurrently at gmail.com  Thu Jun 14 17:33:56 2018
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Thu, 14 Jun 2018 15:33:56 -0600
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
Message-ID: <CALFfu7CzEFdvSURjJBBQYsZ8cS7qgN9jYb-zk+mrp6j27XWwvA@mail.gmail.com>

On Wed, Jun 13, 2018 at 10:16 AM Victor Stinner <vstinner at redhat.com> wrote:
> I propose to promote Pablo Salingo Salgado as a core developer and so
> open a vote during one week. If there is no strong opposition, I will
> promote him but also continue to mentor him for a least one month.
>
> [snip]
>
> I am mentoring Pablo Salingo Salgado since January. I am watching his
> hard work since last September. He made many non trivial and useful
> contributions to Python.
>
> I think that he understands well how Python is developed, is
> respectful, try to find answers alone before asking, and is eager to
> learn. In case of doubt, he ask others before doing something, like
> closing an issue. I trust that Pablo will respect opinions of others,
> like not merging a PR if someone disagree.
>
> [snip]
>
> If Pablo is promoted as a core developer, I propose to continue to be
> his mentor for at least one month, and ask him before merging any PR.

+1

I have had no negative (or any) experiences with Pablo and otherwise
trust Victor's judgement and mentoring.

Regarding if Pablo has done "enough", ultimately folks get commit
privileges at the point that they show they will be a benefit to
Python development and we trust them enough to merge PRs.  Any other
criteria feels rather secondary, considering the variety of ways a
core developer can contribute.  We don't need to aim for exclusivity.
(It's not like we have a limit on the number of people that can have
commit privileges.)  In this case we have a respected core developer
(Victor) expressing his trust, suggesting that Python will benefit via
Pablo, and offering to mentor him.  Unless someone says they do not
trust Pablo, I don't see any reason here to object.

That said, I agree that core developers in particular should be active
on the issue tracker and reviewing PRs, and it makes sense to reward
folks you show a commitment to helping there.  I just don't think that
is necessarily a major criteria for becoming a core developer,
especially when someone like Victor vouches for the candidate.
Sometimes I wonder if we scare off otherwise amazing folks because
they think we expect a significant sacrifice of time or we
inadvertently make them feel like they aren't good enough.  It's easy
for us to mess this up! :/

-eric

From mariatta.wijaya at gmail.com  Thu Jun 14 19:58:31 2018
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Thu, 14 Jun 2018 16:58:31 -0700
Subject: [python-committers] Mentoring Office Hours - the idea,
 and a question
In-Reply-To: <CA+3bQGGxKFTdharHKzp1Jgx9UgWzB6LvSvnVuXf0QnwB+eXLVw@mail.gmail.com>
References: <CAD+XWwqj+mab63zdctmqmcREmV2jy=tjK2FncbnY21wMSVD8GQ@mail.gmail.com>
 <CA+3bQGEQSJtu+T0q9cy2W3yHfUr6ZkApo_DPo+SJ2tuATJQDsQ@mail.gmail.com>
 <CA+3bQGGxKFTdharHKzp1Jgx9UgWzB6LvSvnVuXf0QnwB+eXLVw@mail.gmail.com>
Message-ID: <CAGbohnbSoM+O0YH796ERVqFYVDH=JFv+RkgOYSAhKM+F1Fr9Yg@mail.gmail.com>

Thanks for starting this, Brian.

As such, it needs a person/persons/list to contact should something arise
> in this context that needs to be handled. What/who should that be?

 * Suggestion 2: Create some new list with a few key people on it.
>  * Suggestion 3: List some direct names. Who?


I personally prefer knowing names. If it will be a mailing list, I'd like
to know who are in the mailing list.

Related, I believe there is a new Code of Conduct working group within the
PSF, but I don't know what is the scope of that working group.
https://mail.python.org/pipermail/psf-community/2018-April/000488.html

Perhaps to start it could just be some of us who wants to volunteer and do
it?

I can set aside 1 hr each week Thursday as my office hours, between 7 PM -
8 PM Pacific.



Mariatta

On Wed, May 16, 2018 at 3:08 PM, Victor Stinner <vstinner at redhat.com> wrote:

> 2018-05-16 11:31 GMT-04:00 Victor Stinner <vstinner at redhat.com>:
> > I'm usually available between 10:00 and 16:00 in the French timezone
> > (currently, it's CEST = UTC+2).
>
> Oh, let me be more specific:
>
> 10:00-12:00 and 14:00-16:00, Monday to Friday
>
> Yeah, in France we take our time to eat ;-)
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180614/ff971f38/attachment.html>

From njs at pobox.com  Thu Jun 14 22:05:54 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 14 Jun 2018 19:05:54 -0700
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CAF4280KDHLJDL_x2gY75uMOmpCAzegOEyBXQFc74jt4PD3zYkA@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CAF4280L+Aht5HH1501gifaQHX8HnnXJUj4ZwsV6pYvkBfzJafg@mail.gmail.com>
 <CA+3bQGGCvuVg5oPFjOnNmYv1TxgbDN6A80y0rZkfpsTDZVAbeg@mail.gmail.com>
 <CAF4280KDHLJDL_x2gY75uMOmpCAzegOEyBXQFc74jt4PD3zYkA@mail.gmail.com>
Message-ID: <CAPJVwBn9XAMr3niHmyVdHsYRPKuNerR4OAXfEfUktw6_LEjE5A@mail.gmail.com>

On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksa? <berker.peksag at gmail.com> wrote:
> This isn't about my or someone else's high standards. We keep saying
> we need more triagers and reviewers, and we keep promoting people who
> didn't do any issue triaging and code review. It's not fair to
> contributors who have spent so much time working on these areas.

Surely the solution is to promote more people who do those things, not
to turn away people making other contributions? We need more
contributors of all kinds.

+1 from me.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From brett at python.org  Thu Jun 14 21:27:09 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 14 Jun 2018 18:27:09 -0700
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CALFfu7CzEFdvSURjJBBQYsZ8cS7qgN9jYb-zk+mrp6j27XWwvA@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <CALFfu7CzEFdvSURjJBBQYsZ8cS7qgN9jYb-zk+mrp6j27XWwvA@mail.gmail.com>
Message-ID: <CAP1=2W68suUohjt=pHyY-iCRaH8-5B12qHchDq5s7kw5+APrTA@mail.gmail.com>

I just wanted to say I agree with everything Eric said, for +1 from me.

On Thu, Jun 14, 2018, 14:34 Eric Snow, <ericsnowcurrently at gmail.com> wrote:

> On Wed, Jun 13, 2018 at 10:16 AM Victor Stinner <vstinner at redhat.com>
> wrote:
> > I propose to promote Pablo Salingo Salgado as a core developer and so
> > open a vote during one week. If there is no strong opposition, I will
> > promote him but also continue to mentor him for a least one month.
> >
> > [snip]
> >
> > I am mentoring Pablo Salingo Salgado since January. I am watching his
> > hard work since last September. He made many non trivial and useful
> > contributions to Python.
> >
> > I think that he understands well how Python is developed, is
> > respectful, try to find answers alone before asking, and is eager to
> > learn. In case of doubt, he ask others before doing something, like
> > closing an issue. I trust that Pablo will respect opinions of others,
> > like not merging a PR if someone disagree.
> >
> > [snip]
> >
> > If Pablo is promoted as a core developer, I propose to continue to be
> > his mentor for at least one month, and ask him before merging any PR.
>
> +1
>
> I have had no negative (or any) experiences with Pablo and otherwise
> trust Victor's judgement and mentoring.
>
> Regarding if Pablo has done "enough", ultimately folks get commit
> privileges at the point that they show they will be a benefit to
> Python development and we trust them enough to merge PRs.  Any other
> criteria feels rather secondary, considering the variety of ways a
> core developer can contribute.  We don't need to aim for exclusivity.
> (It's not like we have a limit on the number of people that can have
> commit privileges.)  In this case we have a respected core developer
> (Victor) expressing his trust, suggesting that Python will benefit via
> Pablo, and offering to mentor him.  Unless someone says they do not
> trust Pablo, I don't see any reason here to object.
>
> That said, I agree that core developers in particular should be active
> on the issue tracker and reviewing PRs, and it makes sense to reward
> folks you show a commitment to helping there.  I just don't think that
> is necessarily a major criteria for becoming a core developer,
> especially when someone like Victor vouches for the candidate.
> Sometimes I wonder if we scare off otherwise amazing folks because
> they think we expect a significant sacrifice of time or we
> inadvertently make them feel like they aren't good enough.  It's easy
> for us to mess this up! :/
>
> -eric
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180614/35ff066a/attachment.html>

From angwerzx at 126.com  Fri Jun 15 04:15:36 2018
From: angwerzx at 126.com (Xiang Zhang)
Date: Fri, 15 Jun 2018 16:15:36 +0800 (GMT+08:00)
Subject: [python-committers] CI problem on old pull request
Message-ID: <6fac8fb7.66bf.16402839880.Coremail.angwerzx@126.com>

I have just encountered a problem in PR1958. The appveyor CI prevents me from merging it. I can't see no way to disabling it or rerunning it, no details link. And is it possible to apply our new CIs, like vsts to it now?

Regards
Xiang Zhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180615/91cc5e1e/attachment-0001.html>

From vstinner at redhat.com  Fri Jun 15 04:59:12 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Fri, 15 Jun 2018 10:59:12 +0200
Subject: [python-committers] CI problem on old pull request
In-Reply-To: <6fac8fb7.66bf.16402839880.Coremail.angwerzx@126.com>
References: <6fac8fb7.66bf.16402839880.Coremail.angwerzx@126.com>
Message-ID: <CA+3bQGESsQNvmwoZjWZk9rQwspdAW3wPHzwR6H6msj2ph9Yfaw@mail.gmail.com>

Hi,

It happened sometimes to me one month ago, but then it was fine. The
workaround is to close/reopen the PR. The best way is to use AppVeyor
UI, but here there was no AppVeyor link from the PR.

Close/Reopen worked: AppVeyor is now running.
https://ci.appveyor.com/project/python/cpython/build/3.8build17701

2018-06-15 10:15 GMT+02:00 Xiang Zhang <angwerzx at 126.com>:
> And is it possible to apply our new CIs, like vsts to it now?

VSTS is not perfect neither :-) See for example
https://bugs.python.org/issue33782

Victor

From storchaka at gmail.com  Fri Jun 15 05:14:55 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 15 Jun 2018 12:14:55 +0300
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
Message-ID: <519b816f-aaeb-79a2-4ef3-d7512ce6579c@gmail.com>

13.06.18 23:46, Victor Stinner ????:
> It's not like Pablo proposed the idea himself and force to get this
> feature merged. Pablo just implemented an idea proposed by two other
> core developers.

It looks like Pablo implements ideas for which he does not fully 
understand the consequences and the drawbacks. Well, his skills are not 
bad, but we don't need more half-baken features in the stdlib, it is 
better to have less but more qualitative features that fit well with the 
rest of the stdlib.

> I don't see anything wrong here. It's not uncommon that a newly merged
> feature is still discussed, and I don't see anything wrong with
> Pablo's behaviour here. I don't see how we could prevent such further
> discussions on posix_spawn(). At least, I don't see how Pablo could
> prevent these issues.

My point was that if you count the number of merged PRs, you should 
exclude reverted and unfinished works.

> At the end, I really like the final commit:
> https://github.com/python/cpython/commit/2c15b29aea5d6b9c61aa42d2c24a07ff1edb4b46
>
> It adds a new rounding mode (_PyTime_ROUND_UP), write a non-trivial
> function test for negative timeout, has a good NEWS entry, etc.
>
> Pablo showed that he is able to implement large change and fix all
> cases, not a single case. IMHO it's a good example, rather than a bad
> example :-)

It is just that more than a half of this work was made by you.

>> Many of other PRs are documentation fixes.
> Is it an issue?

No, but these PRs are much easier. And some of them just add the 
documentation for features added in other PRs and should not be count 
separately.

>> I think Pablo will be good core developer and agree with the description
>> given by Victor. But it seems that he still needs to learn something about
>> what changes are good for Python.
> Ok, I account your -1 vote.

Actually just -0. After dropping reverted PRs I have no enough 
information still for having a strong opinion. But I have no strong 
objections if you hold on to him.

> In private, I told Pablo that I consider that the main
> difference between a core developer and a contributor is that core
> developers are expected to spend more time on reviews and mentoring.

The main difference is that the core developer constantly make decisions 
about his own and foreign patches. It is responsible for quality of 
merged code.

IMHO the purpose of adding a new core developer is reducing the burden 
for other core developers. He/she can take a part of the work, make 
qualified reviews and merge PRs without involving attention of BDFL or 
other core developers. For now, Pablo's PRs add the work for core 
developers.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180615/cf38410b/attachment.html>

From angwerzx at 126.com  Fri Jun 15 05:23:33 2018
From: angwerzx at 126.com (Xiang Zhang)
Date: Fri, 15 Jun 2018 17:23:33 +0800 (GMT+08:00)
Subject: [python-committers] CI problem on old pull request
In-Reply-To: <CA+3bQGESsQNvmwoZjWZk9rQwspdAW3wPHzwR6H6msj2ph9Yfaw@mail.gmail.com>
References: <6fac8fb7.66bf.16402839880.Coremail.angwerzx@126.com>
 <CA+3bQGESsQNvmwoZjWZk9rQwspdAW3wPHzwR6H6msj2ph9Yfaw@mail.gmail.com>
Message-ID: <4445af64.6a8f.16402c1d18c.Coremail.angwerzx@126.com>

Thanks. It's working as expected now. :-)




On 06/15/2018 16:59, Victor Stinner wrote:
Hi,

It happened sometimes to me one month ago, but then it was fine. The
workaround is to close/reopen the PR. The best way is to use AppVeyor
UI, but here there was no AppVeyor link from the PR.

Close/Reopen worked: AppVeyor is now running.
https://ci.appveyor.com/project/python/cpython/build/3.8build17701

2018-06-15 10:15 GMT+02:00 Xiang Zhang <angwerzx at 126.com>:
> And is it possible to apply our new CIs, like vsts to it now?

VSTS is not perfect neither :-) See for example
https://bugs.python.org/issue33782

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180615/bda44959/attachment.html>

From storchaka at gmail.com  Fri Jun 15 05:26:46 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 15 Jun 2018 12:26:46 +0300
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CAPJVwBn9XAMr3niHmyVdHsYRPKuNerR4OAXfEfUktw6_LEjE5A@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CAF4280L+Aht5HH1501gifaQHX8HnnXJUj4ZwsV6pYvkBfzJafg@mail.gmail.com>
 <CA+3bQGGCvuVg5oPFjOnNmYv1TxgbDN6A80y0rZkfpsTDZVAbeg@mail.gmail.com>
 <CAF4280KDHLJDL_x2gY75uMOmpCAzegOEyBXQFc74jt4PD3zYkA@mail.gmail.com>
 <CAPJVwBn9XAMr3niHmyVdHsYRPKuNerR4OAXfEfUktw6_LEjE5A@mail.gmail.com>
Message-ID: <65ab848b-3f08-df1b-ecdb-65464ef507b4@gmail.com>

15.06.18 05:05, Nathaniel Smith ????:
> On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksa? <berker.peksag at gmail.com> wrote:
>> This isn't about my or someone else's high standards. We keep saying
>> we need more triagers and reviewers, and we keep promoting people who
>> didn't do any issue triaging and code review. It's not fair to
>> contributors who have spent so much time working on these areas.
> Surely the solution is to promote more people who do those things, not
> to turn away people making other contributions? We need more
> contributors of all kinds.

It is not necessary to be a core developer for been a productive 
contributor. You only need to be a core developer for doing a work that 
can be made only by a core developer. This is mainly merging your own 
and others PRs after a thorough reviewing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180615/934e2d1d/attachment-0001.html>

From ericsnowcurrently at gmail.com  Fri Jun 15 18:37:08 2018
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 15 Jun 2018 16:37:08 -0600
Subject: [python-committers] How to Increase Triage and Code Review
 Activity? (was: Vote to promote Pablo Salingo Salgado as core developer)
In-Reply-To: <CAPJVwBn9XAMr3niHmyVdHsYRPKuNerR4OAXfEfUktw6_LEjE5A@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CAF4280L+Aht5HH1501gifaQHX8HnnXJUj4ZwsV6pYvkBfzJafg@mail.gmail.com>
 <CA+3bQGGCvuVg5oPFjOnNmYv1TxgbDN6A80y0rZkfpsTDZVAbeg@mail.gmail.com>
 <CAF4280KDHLJDL_x2gY75uMOmpCAzegOEyBXQFc74jt4PD3zYkA@mail.gmail.com>
 <CAPJVwBn9XAMr3niHmyVdHsYRPKuNerR4OAXfEfUktw6_LEjE5A@mail.gmail.com>
Message-ID: <CALFfu7BzbHjhhFHO-o1vnwcmwV7i6P12fued=5xTHymiyL3HbA@mail.gmail.com>

On Thu, Jun 14, 2018 at 8:06 PM Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksa? <berker.peksag at gmail.com> wrote:
> > This isn't about my or someone else's high standards. We keep saying
> > we need more triagers and reviewers, and we keep promoting people who
> > didn't do any issue triaging and code review. It's not fair to
> > contributors who have spent so much time working on these areas.

Just to be clear, Berker, I really appreciate the time folks
(including you) put into the more thankless (and often tedious) tasks
like bug triage and code review (and triaging buildbot failures).  I
for one need to spend more of my open-source time on that.  No one
should ever feel like they have to do more than their fair share.

> Surely the solution is to promote more people who do those things, not
> to turn away people making other contributions? We need more
> contributors of all kinds.

I agree completely.  However, Berker's concern is a real (and honest)
one, regardless of its bearing on accepting new core developers.  It
also reflects a real, continuing problem: a shortage of folks doing
bug triage/curation and code review.  Unfortunately, this has a chain
reaction effect by discouraging people from pursuing more involvement
in core development.  For instance, if someone creates a PR but it
sits there for a year they eventually give up.  On the other hand,
sometimes aspiring core contributors question the value of giving a PR
a review if a core committer is going to review it themself before
possibly merging.  (I realize there are good reasons for any code
review, but that is the reaction I've gotten from people on occasion.)

The consequent question is how to get more people resolving open
tracker issues and giving PR reviews?  Off-hand, I'm not sure. :/
We've discussed this before and it's probably time to discuss it
again.  Any ideas?

-eric

From vstinner at redhat.com  Fri Jun 15 19:59:06 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 16 Jun 2018 01:59:06 +0200
Subject: [python-committers] Missing In Action
Message-ID: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>

Hi,

Last months, we debated about the number of *active* core developers.

The problem is that there are 3 lists and each has different numbers
of core developers: 90 according to GitHub, 170 according to
bugs.python.org.

* https://github.com/orgs/python/teams/python-core/members
* https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
* https://devguide.python.org/developers/

I propose to move inactive core developers to a new list (ex:
"Inactive Core Developers") and remove their permission for security
reasons. If the core developer shows up, they will just have to ask a
GitHub administrator (like Brett Cannon) to be added again.

My intent is to enhance security and better track of the current
number of active core developers.

In practice, it should only mean removing these inactive developers
from the list of core developers on bugs.python.org. To make sure that
a developer can become again a core developer, we should track that we
dropped their priviledge. We can add new section in the devguide,
near:
https://devguide.python.org/developers/#permissions-dropped-on-request

There are already two lists of inactive core developers in the
devguide: "Permissions Dropped on Request" and "Permissions Dropped
after Loss of Contact".

I propose to start by removing all core developers who didn't migrate
to GitHub yet, since it's a simple way to check if they are active
since February 2017.

I can work on a concrete list of developers, but it seems like it will
take me some time. Some developers are cores according to
bugs.python.org but I cannot find them in the devguide list. Some
developers are no longer core devs according to devguide, but still
core in bugs.python.org. There are some inconsistencies.

Victor

From vstinner at redhat.com  Fri Jun 15 20:03:53 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 16 Jun 2018 02:03:53 +0200
Subject: [python-committers] Missing In Action
In-Reply-To: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
Message-ID: <CA+3bQGFnDkd_E_ua2NMTtQuroCg9VzJRScAXX3TXdY1ZJgsZdw@mail.gmail.com>

"Missing In Action"

Oh. After I sent my email, I checked the translation of "Missing In
Action". It means more or less "lost", but it seems to be commonly
associated to war:

https://en.wikipedia.org/wiki/Missing_in_action
"a casualty classification assigned to combatants, military chaplains,
combat medics, and prisoners of war who are reported missing during
wartime or ceasefire"

I don't recall where I heard the expression, but I didn't mean that
inactive developers are dead :-) I'm quite sure that there is life
after Python. Right?

Victor

From vstinner at redhat.com  Fri Jun 15 20:43:48 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 16 Jun 2018 02:43:48 +0200
Subject: [python-committers] Maintenance Tasks
Message-ID: <CA+3bQGGVAq3DPwraP-YpF8YPJXF-ynT+nCwGmeDB19EqfHHA2w@mail.gmail.com>

Hi,

At FOSDEM (last February), I saw an interesting talk by VM (Vicky) Brasseur:
"Passing the Baton: Succession planning for FOSS leadership"

She explains that the maintenance of a project should be splited into
small tasks, and that each task should be done by at least two people.
Why at least two, and not only one? Well, sometimes you may want to
take holiday, one of your family member may become sick, or maybe you
are simply bored and wants to do something else. You may have heard
about the "bus factor", but I dislike this name because it sounds like
a very unlikely event, whereas people leaving for whatever reason is
common.

It's also about documenting what you are doing to be able to pass the
task to someone else. What should be documented? Well, here is where
the second player matters: document enough until someone else is
autonomous on the task.

What are Python maintenance tasks? I identified the following tasks:
http://pythondev.readthedocs.io/maintenance_tasks.html

Copy of my list:

* `Review and merge pull requests
<https://github.com/python/cpython/pulls>`_. The merge action is
restricted to core developers.
  Maintainers: active core developers (June 2018: around 34 core devs).
* `Bug triage <https://bugs.python.org/>`_: closing a bug requires the
bug triage
  permission. Maintainers: active core developers.
* `Check for buildbot failures
  <https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/>`_:
  Read logs of each buildbot failure, check if the failure is known. If the
  failure is known, maybe mention the new failure in the existing bug.
  Otherwise, open a new bug. Then reply to the email with a link to the bug.
  Maintainers: Victor Stinner, Pablo Salingo Salgado.
* Run bugs.python.org: fix bugs, deploy new version. See the
  `meta bug tracker <http://psf.upfronthosting.co.za/roundup/meta/>`_ for bugs
  of bugs.python.org itself (not for Python bugs). Roundup is going to be
  deployed in a Docker container on OpenShift. Maintainers:
  Ezio Melotti, Brett Cannon, Maciej Szulik.
* `Run pythontest.net <http://www.pythontest.net/>`_. Maintainers: ?
* Run GitHub bots. Maintainers: Brett Cannon and Mariatta Wijaya.
* Update vendored external libraries. Maintainers: ?
* Update unicodedata on new Unicode release. Latest update (Unicode 11.0):
  https://bugs.python.org/issue33778. Maintainer: Benajamin Peterson.

I likely forget many tasks, since "maintenance" is a large topic and
there are some tasks that are only be done rarely (like releases?).


By the way, I also started to list known administrators. Some actions
require administrators who are the only ones allowed to do actions.

* Mailing lists: create a new mailing list. Maintainer: "postmaster" (who is
  the current postmaster?).
* Bug tracker: give "bug triage permission". Administrators: Ezio Melotti,
  Ned Deily(?), R. David Murray.
* GitHub cpython: add new core developers. Administrators: Brett Cannon,
  Ned Deily, others(?).


I chose to start discussing maintenance tasks with core developers
only (python-committers mailing list) since many tasks are reserved to
(or at least currently done by) core developers. And I'm not sure that
the concept of "maintenance tasks" makes sense, so I prefer to start
discussing it with smaller audience :-)

Note: The talk title is "Passing the Baton: Succession planning for
FOSS leadership", but I don't ask here your BDFL to pass the baton ;-)
I'm talking about the rest of talk.

Victor

From vstinner at redhat.com  Fri Jun 15 21:14:29 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 16 Jun 2018 03:14:29 +0200
Subject: [python-committers] Missing In Action
In-Reply-To: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
Message-ID: <CA+3bQGFXAC1mt6CJshCdGwNfwEKw5=2e2+joHuSuQ8GeEp1wMA@mail.gmail.com>

This idea also comes from Brett Cannon who proposed something similar:
https://mail.python.org/pipermail/python-committers/2018-June/005526.html

Victor

2018-06-16 1:59 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> Hi,
>
> Last months, we debated about the number of *active* core developers.
>
> The problem is that there are 3 lists and each has different numbers
> of core developers: 90 according to GitHub, 170 according to
> bugs.python.org.
>
> * https://github.com/orgs/python/teams/python-core/members
> * https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
> * https://devguide.python.org/developers/
>
> I propose to move inactive core developers to a new list (ex:
> "Inactive Core Developers") and remove their permission for security
> reasons. If the core developer shows up, they will just have to ask a
> GitHub administrator (like Brett Cannon) to be added again.
>
> My intent is to enhance security and better track of the current
> number of active core developers.
>
> In practice, it should only mean removing these inactive developers
> from the list of core developers on bugs.python.org. To make sure that
> a developer can become again a core developer, we should track that we
> dropped their priviledge. We can add new section in the devguide,
> near:
> https://devguide.python.org/developers/#permissions-dropped-on-request
>
> There are already two lists of inactive core developers in the
> devguide: "Permissions Dropped on Request" and "Permissions Dropped
> after Loss of Contact".
>
> I propose to start by removing all core developers who didn't migrate
> to GitHub yet, since it's a simple way to check if they are active
> since February 2017.
>
> I can work on a concrete list of developers, but it seems like it will
> take me some time. Some developers are cores according to
> bugs.python.org but I cannot find them in the devguide list. Some
> developers are no longer core devs according to devguide, but still
> core in bugs.python.org. There are some inconsistencies.
>
> Victor

From vstinner at redhat.com  Fri Jun 15 21:17:22 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 16 Jun 2018 03:17:22 +0200
Subject: [python-committers] Maintenance Tasks
In-Reply-To: <CA+3bQGGVAq3DPwraP-YpF8YPJXF-ynT+nCwGmeDB19EqfHHA2w@mail.gmail.com>
References: <CA+3bQGGVAq3DPwraP-YpF8YPJXF-ynT+nCwGmeDB19EqfHHA2w@mail.gmail.com>
Message-ID: <CA+3bQGHo=wqgw7c5bGGbk56SE3jkAO9YP0EmgSXJ6yGjmr8NXg@mail.gmail.com>

> At FOSDEM (last February), I saw an interesting talk by VM (Vicky) Brasseur:
> "Passing the Baton: Succession planning for FOSS leadership"

Sorry, I forgot the link to the video and slides:
https://fosdem.org/2018/schedule/event/community_passing_the_batton_foss_leadership/

Victor

From storchaka at gmail.com  Sat Jun 16 01:27:22 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 16 Jun 2018 08:27:22 +0300
Subject: [python-committers] Missing In Action
In-Reply-To: <CA+3bQGFnDkd_E_ua2NMTtQuroCg9VzJRScAXX3TXdY1ZJgsZdw@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <CA+3bQGFnDkd_E_ua2NMTtQuroCg9VzJRScAXX3TXdY1ZJgsZdw@mail.gmail.com>
Message-ID: <a9ed84f4-9cd2-42d9-2a6f-ebdf5f31bd1e@gmail.com>

16.06.18 03:03, Victor Stinner ????:

> Oh. After I sent my email, I checked the translation of "Missing In
> Action". It means more or less "lost", but it seems to be commonly
> associated to war:

Good illustration of the loss in translation. :-)


From storchaka at gmail.com  Sat Jun 16 01:34:51 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 16 Jun 2018 08:34:51 +0300
Subject: [python-committers] Missing In Action
In-Reply-To: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
Message-ID: <eff54f6b-0539-f771-9e03-4671304a35d2@gmail.com>

16.06.18 02:59, Victor Stinner ????:

> The problem is that there are 3 lists and each has different numbers
> of core developers: 90 according to GitHub, 170 according to
> bugs.python.org.
>
> * https://github.com/orgs/python/teams/python-core/members
> * https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
> * https://devguide.python.org/developers/

There is also a list of experts:

* https://devguide.python.org/experts/

It contains not only core developers, but third-party experts. Some 
names are flagged with "(inactive)" or a star.


From jack.jansen at cwi.nl  Sun Jun 17 17:29:34 2018
From: jack.jansen at cwi.nl (Jack Jansen)
Date: Sun, 17 Jun 2018 23:29:34 +0200
Subject: [python-committers] Missing In Action
In-Reply-To: <CA+3bQGFnDkd_E_ua2NMTtQuroCg9VzJRScAXX3TXdY1ZJgsZdw@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <CA+3bQGFnDkd_E_ua2NMTtQuroCg9VzJRScAXX3TXdY1ZJgsZdw@mail.gmail.com>
Message-ID: <6A17A502-028E-422C-8C8C-2AF0AC8F01CE@cwi.nl>

I think I am one of those core developers who hasn?t committed anything in ages (even though I do have a git account and am somewhat following what goes on), but the term missing in action may be a bit too loaded?.

How about ?missing in inaction??

:-)

Jack


> On  16-Jun-2018, at 02:03 , Victor Stinner <vstinner at redhat.com> wrote:
> 
> "Missing In Action"
> 
> Oh. After I sent my email, I checked the translation of "Missing In
> Action". It means more or less "lost", but it seems to be commonly
> associated to war:
> 
> https://en.wikipedia.org/wiki/Missing_in_action
> "a casualty classification assigned to combatants, military chaplains,
> combat medics, and prisoners of war who are reported missing during
> wartime or ceasefire"
> 
> I don't recall where I heard the expression, but I didn't mean that
> inactive developers are dead :-) I'm quite sure that there is life
> after Python. Right?
> 
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180617/498d565f/attachment.html>

From brett at python.org  Sun Jun 17 21:18:07 2018
From: brett at python.org (Brett Cannon)
Date: Sun, 17 Jun 2018 18:18:07 -0700
Subject: [python-committers] Missing In Action
In-Reply-To: <6A17A502-028E-422C-8C8C-2AF0AC8F01CE@cwi.nl>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <CA+3bQGFnDkd_E_ua2NMTtQuroCg9VzJRScAXX3TXdY1ZJgsZdw@mail.gmail.com>
 <6A17A502-028E-422C-8C8C-2AF0AC8F01CE@cwi.nl>
Message-ID: <CAP1=2W5d1=iRrKes=cACEnd8pKzrB4JV=LrvY0WKoJJhnYEq8A@mail.gmail.com>

We could call them  "dormant".

And I obviously support culling our membership list for the exact reasons
Victor listed (especially since I was planning to do this at some point
anyway :) .

My only question is whether we care about leaving people on b.p.o who have
gone dormant with triage privileges as well? It's much less important, but
if they haven't contributed in a while they probably are not up to sped
with triage practices and thus might do something wrong by accident.

On Sun, 17 Jun 2018 at 14:38 Jack Jansen <jack.jansen at cwi.nl> wrote:

> I think I am one of those core developers who hasn?t committed anything in
> ages (even though I do have a git account and am somewhat following what
> goes on), but the term missing in action may be a bit too loaded?.
>
> How about ?missing in inaction??
>
> :-)
>
> Jack
>
>
> On  16-Jun-2018, at 02:03 , Victor Stinner <vstinner at redhat.com> wrote:
>
> "Missing In Action"
>
> Oh. After I sent my email, I checked the translation of "Missing In
> Action". It means more or less "lost", but it seems to be commonly
> associated to war:
>
> https://en.wikipedia.org/wiki/Missing_in_action
> "a casualty classification assigned to combatants, military chaplains,
> combat medics, and prisoners of war who are reported missing during
> wartime or ceasefire"
>
> I don't recall where I heard the expression, but I didn't mean that
> inactive developers are dead :-) I'm quite sure that there is life
> after Python. Right?
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
> --
>
> Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
>
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180617/3116e226/attachment.html>

From eric at trueblade.com  Sun Jun 17 21:21:05 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Sun, 17 Jun 2018 21:21:05 -0400
Subject: [python-committers] Missing In Action
In-Reply-To: <CAP1=2W5d1=iRrKes=cACEnd8pKzrB4JV=LrvY0WKoJJhnYEq8A@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <CA+3bQGFnDkd_E_ua2NMTtQuroCg9VzJRScAXX3TXdY1ZJgsZdw@mail.gmail.com>
 <6A17A502-028E-422C-8C8C-2AF0AC8F01CE@cwi.nl>
 <CAP1=2W5d1=iRrKes=cACEnd8pKzrB4JV=LrvY0WKoJJhnYEq8A@mail.gmail.com>
Message-ID: <8f104faf-ca08-9fa3-4521-dae4960741dc@trueblade.com>

On 6/17/2018 9:18 PM, Brett Cannon wrote:
> We could call them? "dormant".

Sounds good.

> And I obviously support culling our membership list for the exact 
> reasons Victor listed (especially since I was planning to do this at 
> some point anyway :) .
> 
> My only question is whether we care about leaving people on b.p.o who 
> have gone dormant with triage privileges as well? It's much less 
> important, but if they haven't contributed in a while they probably are 
> not up to sped with triage practices and thus might do something wrong 
> by accident.

I think disabling their access is a good idea from an infosec 
perspective. It's not like it's onerous to re-enable them if they 
express any renewed interest.

Eric

> 
> On Sun, 17 Jun 2018 at 14:38 Jack Jansen <jack.jansen at cwi.nl 
> <mailto:jack.jansen at cwi.nl>> wrote:
> 
>     I think I am one of those core developers who hasn?t committed
>     anything in ages (even though I do have a git account and am
>     somewhat following what goes on), but the term missing in action may
>     be a bit too loaded?.
> 
>     How about ?missing in inaction??
> 
>     :-)
> 
>     Jack
> 
> 
>>     On ?16-Jun-2018, at 02:03 , Victor Stinner <vstinner at redhat.com
>>     <mailto:vstinner at redhat.com>> wrote:
>>
>>     "Missing In Action"
>>
>>     Oh. After I sent my email, I checked the translation of "Missing In
>>     Action". It means more or less "lost", but it seems to be commonly
>>     associated to war:
>>
>>     https://en.wikipedia.org/wiki/Missing_in_action
>>     "a casualty classification assigned to combatants, military chaplains,
>>     combat medics, and prisoners of war who are reported missing during
>>     wartime or ceasefire"
>>
>>     I don't recall where I heard the expression, but I didn't mean that
>>     inactive developers are dead :-) I'm quite sure that there is life
>>     after Python. Right?
>>
>>     Victor
>>     _______________________________________________
>>     python-committers mailing list
>>     python-committers at python.org <mailto:python-committers at python.org>
>>     https://mail.python.org/mailman/listinfo/python-committers
>>     Code of Conduct: https://www.python.org/psf/codeofconduct/
> 
>     --
> 
>     Jack Jansen, <Jack.Jansen at cwi.nl <mailto:Jack.Jansen at cwi.nl>>,
>     http://www.cwi.nl/~jack <http://www.cwi.nl/%7Ejack>
> 
>     If I can't dance I don't want to be part of your revolution -- Emma
>     Goldman
> 
> 
> 
> 
>     _______________________________________________
>     python-committers mailing list
>     python-committers at python.org <mailto:python-committers at python.org>
>     https://mail.python.org/mailman/listinfo/python-committers
>     Code of Conduct: https://www.python.org/psf/codeofconduct/
> 
> 
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

From mal at egenix.com  Mon Jun 18 04:07:09 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 18 Jun 2018 10:07:09 +0200
Subject: [python-committers] Changing commiter status (was: Missing In
 Action)
In-Reply-To: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
Message-ID: <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>

Victor:

please make sure that you contact the developers whos status
you intend to modify prior to doing so. Being a core developer
of Python is a status and not something that should be changed
without consent by the developer in question.

Also note that the dev list log doesn't include all core developers.
Data from before the move to SVN in 2006 is essentially missing,
since AFAIK we never kept around a log of who received the core
bit before that.

And there were times when the core bit itself did not exist, since
all patches had to go through the small team around Guido
which had access to the CVS system at the time.

Overall, I think that removing repo or bpo permissions should be
kept separate from the status itself. It would probably be wise
to send around reminders to all core devs who have access and
have not used their permissions every few year. The keys of those
who don't respond could then be disabled, without affecting
anything else; and, of course, easily be reenabled if needed,
without much process either.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jun 18 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/



On 16.06.2018 01:59, Victor Stinner wrote:
> Hi,
> 
> Last months, we debated about the number of *active* core developers.
> 
> The problem is that there are 3 lists and each has different numbers
> of core developers: 90 according to GitHub, 170 according to
> bugs.python.org.
> 
> * https://github.com/orgs/python/teams/python-core/members
> * https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
> * https://devguide.python.org/developers/
> 
> I propose to move inactive core developers to a new list (ex:
> "Inactive Core Developers") and remove their permission for security
> reasons. If the core developer shows up, they will just have to ask a
> GitHub administrator (like Brett Cannon) to be added again.
> 
> My intent is to enhance security and better track of the current
> number of active core developers.
> 
> In practice, it should only mean removing these inactive developers
> from the list of core developers on bugs.python.org. To make sure that
> a developer can become again a core developer, we should track that we
> dropped their priviledge. We can add new section in the devguide,
> near:
> https://devguide.python.org/developers/#permissions-dropped-on-request
> 
> There are already two lists of inactive core developers in the
> devguide: "Permissions Dropped on Request" and "Permissions Dropped
> after Loss of Contact".
> 
> I propose to start by removing all core developers who didn't migrate
> to GitHub yet, since it's a simple way to check if they are active
> since February 2017.
> 
> I can work on a concrete list of developers, but it seems like it will
> take me some time. Some developers are cores according to
> bugs.python.org but I cannot find them in the devguide list. Some
> developers are no longer core devs according to devguide, but still
> core in bugs.python.org. There are some inconsistencies.
> 
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 


From ncoghlan at gmail.com  Mon Jun 18 09:34:41 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 18 Jun 2018 23:34:41 +1000
Subject: [python-committers] Changing commiter status (was: Missing In
 Action)
In-Reply-To: <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
Message-ID: <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>

On 18 June 2018 at 18:07, M.-A. Lemburg <mal at egenix.com> wrote:
> Overall, I think that removing repo or bpo permissions should be
> kept separate from the status itself. It would probably be wise
> to send around reminders to all core devs who have access and
> have not used their permissions every few year. The keys of those
> who don't respond could then be disabled, without affecting
> anything else; and, of course, easily be reenabled if needed,
> without much process either.

Aye, that's the key concept behind adding an explicit "Dormant" status
for core developers - they're folks that are still trusted with core
commit privileges if they choose to exercise them, but while they're
not using their access, it's better to deactivate their credentials to
reduce the potential for compromise.

We'd add a note to the developer guide that gave instructions on how
to request reactivation (likely just "Check the developer guide to
ensure you're up to speed with any changes since you were last active,
then past to python-committers requesting that your credentials be
reactivated").

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From antoine at python.org  Mon Jun 18 14:17:03 2018
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 18 Jun 2018 20:17:03 +0200
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <d9b83569-8cf1-fc3f-7158-b4354e1e32b8@udel.edu>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
 <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
 <d9b83569-8cf1-fc3f-7158-b4354e1e32b8@udel.edu>
Message-ID: <70684ccd-8a3d-50f9-7509-5ad8ddf9d91b@python.org>


Le 14/06/2018 ? 04:30, Terry Reedy a ?crit?:
> On 6/13/2018 7:03 PM, Carol Willing wrote:
>> +1 With Victor's mentoring (1 or 2 months), I believe that it is 
>> reasonable to promote Pablo to a core developer either now or after 3 
>> months of coaching.
>>
>> I would also like to see Cheryl Sabella who has been very active on the 
>> bug tracker to also be promoted to a core developer.
> 
> A bit off topic, but I would too, as she has been extremely helpful with 
> IDLE. 

It's very nice that we're getting new active contributors.
OTOH if Cheryl is mostly active on the bug tracker, does she need commit
rights in order to participate properly?  Or did she also review PRs or
submit some of her own?

Regards

Antoine.

From antoine at python.org  Mon Jun 18 14:25:18 2018
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 18 Jun 2018 20:25:18 +0200
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CAGE7PNLO3wJW0AOwghvksJH7H3S4MJD0FveAhLiETV2_j1N+VQ@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <CA+3bQGErGm6kim5N9gC3BxJUL46UGB=7dbuZ5nAEt-dzUdFT3Q@mail.gmail.com>
 <CAGE7PNLO3wJW0AOwghvksJH7H3S4MJD0FveAhLiETV2_j1N+VQ@mail.gmail.com>
Message-ID: <cab83ca9-4b1c-ccdf-2484-ae47db437576@python.org>


Le 14/06/2018 ? 19:25, Gregory P. Smith a ?crit?:
> Quick response:
> 
> +0.5
> 
> But Pablo shows drive and desire to do good things and an
> ability to eventually do it even if there are learning bumps along the
> way.

This is my impression as well, having interacted with Pablo on a single
PR on which I ended up proposing another approach that I implemented myself.

> With mentoring and PR reviews (which I'm assuming Victor is
> signing up for) I believe Pablo would make a fine core developer.
> 
> So?+0.5 from me.? I wouldn't give Pablo free reign to make changes yet -
> mentoring required - but that is exactly how most of us start off while
> we learn.

Same feeling here.  Also Pablo seems to tackle non-trivial issues, which
may explain some of the clumsiness.  +0.5 from me.

Regards

Antoine.

From brett at python.org  Mon Jun 18 14:37:13 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 18 Jun 2018 11:37:13 -0700
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <70684ccd-8a3d-50f9-7509-5ad8ddf9d91b@python.org>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
 <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
 <d9b83569-8cf1-fc3f-7158-b4354e1e32b8@udel.edu>
 <70684ccd-8a3d-50f9-7509-5ad8ddf9d91b@python.org>
Message-ID: <CAP1=2W7sKDr6jGTWjWV0r46j_pUeDSns41261Kj6hyZvfoi3Ww@mail.gmail.com>

On Mon, 18 Jun 2018 at 11:17 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 14/06/2018 ? 04:30, Terry Reedy a ?crit :
> > On 6/13/2018 7:03 PM, Carol Willing wrote:
> >> +1 With Victor's mentoring (1 or 2 months), I believe that it is
> >> reasonable to promote Pablo to a core developer either now or after 3
> >> months of coaching.
> >>
> >> I would also like to see Cheryl Sabella who has been very active on the
> >> bug tracker to also be promoted to a core developer.
> >
> > A bit off topic, but I would too, as she has been extremely helpful with
> > IDLE.
>
> It's very nice that we're getting new active contributors.
> OTOH if Cheryl is mostly active on the bug tracker, does she need commit
> rights in order to participate properly?  Or did she also review PRs or
> submit some of her own?
>
>
Cheryl is actually the 6th most active contributor by commits over the past
year:
https://github.com/python/cpython/graphs/contributors?from=2017-06-18&to=2018-06-18&type=c
(IOW only Victor, you, Yury, Terry, and Ned have more commits since
2017-06-18).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/2dd42b6f/attachment.html>

From brett at python.org  Mon Jun 18 14:40:54 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 18 Jun 2018 11:40:54 -0700
Subject: [python-committers] Maintenance Tasks
In-Reply-To: <CA+3bQGGVAq3DPwraP-YpF8YPJXF-ynT+nCwGmeDB19EqfHHA2w@mail.gmail.com>
References: <CA+3bQGGVAq3DPwraP-YpF8YPJXF-ynT+nCwGmeDB19EqfHHA2w@mail.gmail.com>
Message-ID: <CAP1=2W5faZEude7iZL7W=4WJjhkgNuVG4_FdOR7gJ3SpDPNi9w@mail.gmail.com>

On Fri, 15 Jun 2018 at 17:44 Victor Stinner <vstinner at redhat.com> wrote:

> Hi,
>
> At FOSDEM (last February), I saw an interesting talk by VM (Vicky)
> Brasseur:
> "Passing the Baton: Succession planning for FOSS leadership"
>
> She explains that the maintenance of a project should be splited into
> small tasks, and that each task should be done by at least two people.
> Why at least two, and not only one? Well, sometimes you may want to
> take holiday, one of your family member may become sick, or maybe you
> are simply bored and wants to do something else. You may have heard
> about the "bus factor", but I dislike this name because it sounds like
> a very unlikely event, whereas people leaving for whatever reason is
> common.
>
> It's also about documenting what you are doing to be able to pass the
> task to someone else. What should be documented? Well, here is where
> the second player matters: document enough until someone else is
> autonomous on the task.
>
> What are Python maintenance tasks? I identified the following tasks:
> http://pythondev.readthedocs.io/maintenance_tasks.html
>
> Copy of my list:
>
> * `Review and merge pull requests
> <https://github.com/python/cpython/pulls>`_. The merge action is
> restricted to core developers.
>   Maintainers: active core developers (June 2018: around 34 core devs).
> * `Bug triage <https://bugs.python.org/>`_: closing a bug requires the
> bug triage
>   permission. Maintainers: active core developers.
> * `Check for buildbot failures
>   <https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/
> >`_:
>   Read logs of each buildbot failure, check if the failure is known. If the
>   failure is known, maybe mention the new failure in the existing bug.
>   Otherwise, open a new bug. Then reply to the email with a link to the
> bug.
>   Maintainers: Victor Stinner, Pablo Salingo Salgado.
> * Run bugs.python.org: fix bugs, deploy new version. See the
>   `meta bug tracker <http://psf.upfronthosting.co.za/roundup/meta/>`_ for
> bugs
>   of bugs.python.org itself (not for Python bugs). Roundup is going to be
>   deployed in a Docker container on OpenShift. Maintainers:
>   Ezio Melotti, Brett Cannon, Maciej Szulik.
>

I'm not a maintainer of bugs.python.org.


> * `Run pythontest.net <http://www.pythontest.net/>`_. Maintainers: ?
> * Run GitHub bots. Maintainers: Brett Cannon and Mariatta Wijaya.
> * Update vendored external libraries. Maintainers: ?
> * Update unicodedata on new Unicode release. Latest update (Unicode 11.0):
>   https://bugs.python.org/issue33778. Maintainer: Benajamin Peterson.
>
> I likely forget many tasks, since "maintenance" is a large topic and
> there are some tasks that are only be done rarely (like releases?).
>
>
> By the way, I also started to list known administrators. Some actions
> require administrators who are the only ones allowed to do actions.
>
> * Mailing lists: create a new mailing list. Maintainer: "postmaster" (who
> is
>   the current postmaster?).
>

There's a couple.


> * Bug tracker: give "bug triage permission". Administrators: Ezio Melotti,
>   Ned Deily(?), R. David Murray.
>

Also me.


> * GitHub cpython: add new core developers. Administrators: Brett Cannon,
>   Ned Deily, others(?).
>

Me and any release manager.

-Brett


>
>
> I chose to start discussing maintenance tasks with core developers
> only (python-committers mailing list) since many tasks are reserved to
> (or at least currently done by) core developers. And I'm not sure that
> the concept of "maintenance tasks" makes sense, so I prefer to start
> discussing it with smaller audience :-)
>
> Note: The talk title is "Passing the Baton: Succession planning for
> FOSS leadership", but I don't ask here your BDFL to pass the baton ;-)
> I'm talking about the rest of talk.
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/5e8a8721/attachment-0001.html>

From antoine at python.org  Mon Jun 18 14:48:58 2018
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 18 Jun 2018 20:48:58 +0200
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CAP1=2W7sKDr6jGTWjWV0r46j_pUeDSns41261Kj6hyZvfoi3Ww@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
 <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
 <d9b83569-8cf1-fc3f-7158-b4354e1e32b8@udel.edu>
 <70684ccd-8a3d-50f9-7509-5ad8ddf9d91b@python.org>
 <CAP1=2W7sKDr6jGTWjWV0r46j_pUeDSns41261Kj6hyZvfoi3Ww@mail.gmail.com>
Message-ID: <f8b2039f-bde7-2081-83c7-f749268e10e9@python.org>


Thanks for correcting me.
(by the way I'm 8th in that list... Serhiy is 2nd, not me ;-))

Regards

Antoine.


Le 18/06/2018 ? 20:37, Brett Cannon a ?crit?:
> 
> 
> On Mon, 18 Jun 2018 at 11:17 Antoine Pitrou <antoine at python.org
> <mailto:antoine at python.org>> wrote:
> 
> 
>     Le 14/06/2018 ? 04:30, Terry Reedy a ?crit?:
>     > On 6/13/2018 7:03 PM, Carol Willing wrote:
>     >> +1 With Victor's mentoring (1 or 2 months), I believe that it is
>     >> reasonable to promote Pablo to a core developer either now or
>     after 3
>     >> months of coaching.
>     >>
>     >> I would also like to see Cheryl Sabella who has been very active
>     on the
>     >> bug tracker to also be promoted to a core developer.
>     >
>     > A bit off topic, but I would too, as she has been extremely
>     helpful with
>     > IDLE.
> 
>     It's very nice that we're getting new active contributors.
>     OTOH if Cheryl is mostly active on the bug tracker, does she need commit
>     rights in order to participate properly?? Or did she also review PRs or
>     submit some of her own?
> 
> 
> Cheryl is actually the 6th most active contributor by commits over the
> past year:
> https://github.com/python/cpython/graphs/contributors?from=2017-06-18&to=2018-06-18&type=c
> (IOW only Victor, you, Yury, Terry, and Ned have more commits since
> 2017-06-18).

From antoine at python.org  Mon Jun 18 14:52:17 2018
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 18 Jun 2018 20:52:17 +0200
Subject: [python-committers] Maintenance Tasks
In-Reply-To: <CA+3bQGGVAq3DPwraP-YpF8YPJXF-ynT+nCwGmeDB19EqfHHA2w@mail.gmail.com>
References: <CA+3bQGGVAq3DPwraP-YpF8YPJXF-ynT+nCwGmeDB19EqfHHA2w@mail.gmail.com>
Message-ID: <858acd89-5e6a-21d0-8952-1e1399b7a14b@python.org>


Le 16/06/2018 ? 02:43, Victor Stinner a ?crit?:
> 
> I chose to start discussing maintenance tasks with core developers
> only (python-committers mailing list) since many tasks are reserved to
> (or at least currently done by) core developers. And I'm not sure that
> the concept of "maintenance tasks" makes sense, so I prefer to start
> discussing it with smaller audience :-)

I would say that maintenance tasks are probably 90% of CPython
development (in the broad sense) these days.  Well, until a team of
experienced developers decide to work full time on a JIT for 3/4 years,
of course ;-)

Regards

Antoine.

From brett at python.org  Mon Jun 18 14:03:36 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 18 Jun 2018 11:03:36 -0700
Subject: [python-committers] Changing commiter status (was: Missing In
 Action)
In-Reply-To: <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
Message-ID: <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>

On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 18 June 2018 at 18:07, M.-A. Lemburg <mal at egenix.com> wrote:
> > Overall, I think that removing repo or bpo permissions should be
> > kept separate from the status itself. It would probably be wise
> > to send around reminders to all core devs who have access and
> > have not used their permissions every few year. The keys of those
> > who don't respond could then be disabled, without affecting
> > anything else; and, of course, easily be reenabled if needed,
> > without much process either.
>
> Aye, that's the key concept behind adding an explicit "Dormant" status
> for core developers - they're folks that are still trusted with core
> commit privileges if they choose to exercise them, but while they're
> not using their access, it's better to deactivate their credentials to
> reduce the potential for compromise.
>
> We'd add a note to the developer guide that gave instructions on how
> to request reactivation (likely just "Check the developer guide to
> ensure you're up to speed with any changes since you were last active,
> then past to python-committers requesting that your credentials be
> reactivated").
>

Right, no one's role of having been a core dev will be wiped from history,
they just won't have the core dev logo next to their bugs.python.org
username in the issue tracker (which if they are so dormant to have not
added their GitHub username then  they probably don't care about that
anyway ;) . And flipping everything back on is a radio button and a word in
bugs.python.org if their triage rights are removed and clicking on a button
on a web page on GitHub if we clean up for dev access on the repository.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/75021017/attachment.html>

From guido at python.org  Mon Jun 18 15:07:34 2018
From: guido at python.org (Guido van Rossum)
Date: Mon, 18 Jun 2018 12:07:34 -0700
Subject: [python-committers] Changing commiter status (was: Missing In
 Action)
In-Reply-To: <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
Message-ID: <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>

Hm, unless I misunderstood, MAL's

> Being a core developer of Python is a status

suggests that core devs might want to keep this status since it confers
"status" on their person (it looks good on a resume for sure). And I
wouldn't want to make it any harder for a 3rd party to verify someone's
claim to this status in their resume.

Marc-Andre, is that what you meant?

On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett at python.org> wrote:

>
>
> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 18 June 2018 at 18:07, M.-A. Lemburg <mal at egenix.com> wrote:
>> > Overall, I think that removing repo or bpo permissions should be
>> > kept separate from the status itself. It would probably be wise
>> > to send around reminders to all core devs who have access and
>> > have not used their permissions every few year. The keys of those
>> > who don't respond could then be disabled, without affecting
>> > anything else; and, of course, easily be reenabled if needed,
>> > without much process either.
>>
>> Aye, that's the key concept behind adding an explicit "Dormant" status
>> for core developers - they're folks that are still trusted with core
>> commit privileges if they choose to exercise them, but while they're
>> not using their access, it's better to deactivate their credentials to
>> reduce the potential for compromise.
>>
>> We'd add a note to the developer guide that gave instructions on how
>> to request reactivation (likely just "Check the developer guide to
>> ensure you're up to speed with any changes since you were last active,
>> then past to python-committers requesting that your credentials be
>> reactivated").
>>
>
> Right, no one's role of having been a core dev will be wiped from history,
> they just won't have the core dev logo next to their bugs.python.org
> username in the issue tracker (which if they are so dormant to have not
> added their GitHub username then  they probably don't care about that
> anyway ;) . And flipping everything back on is a radio button and a word in
> bugs.python.org if their triage rights are removed and clicking on a
> button on a web page on GitHub if we clean up for dev access on the
> repository.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/3e03d0f8/attachment-0001.html>

From jack.jansen at cwi.nl  Mon Jun 18 15:24:19 2018
From: jack.jansen at cwi.nl (Jack Jansen)
Date: Mon, 18 Jun 2018 21:24:19 +0200
Subject: [python-committers] Changing commiter status (was: Missing In
 Action)
In-Reply-To: <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
Message-ID: <CFFB98A1-2CCB-4D37-858F-939E6852C696@cwi.nl>

I know that this is the case for me.

I wouldn?t _dream_ of committing anything (after 10 years or so) without first consulting with current core developers, etc. But formally being a Python core dev does give me status with my colleagues, students, children (well, one only), nephews and nieces, etc. and I have just enough vanity to kind of enjoy that. Just the other day a nephew took a selfie of the two of us and posted it to all friends, YES! :-)

That said: I would fully understand if my status was changed to ?dormant core dev? or ?retired core dev? and I wouldn?t have any problems with that.

Jack


> On  18-Jun-2018, at 21:07 , Guido van Rossum <guido at python.org> wrote:
> 
> Hm, unless I misunderstood, MAL's
> 
> > Being a core developer of Python is a status
> 
> suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
> 
> Marc-Andre, is that what you meant?
> 
> On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> 
> 
> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> wrote:
> On 18 June 2018 at 18:07, M.-A. Lemburg <mal at egenix.com <mailto:mal at egenix.com>> wrote:
> > Overall, I think that removing repo or bpo permissions should be
> > kept separate from the status itself. It would probably be wise
> > to send around reminders to all core devs who have access and
> > have not used their permissions every few year. The keys of those
> > who don't respond could then be disabled, without affecting
> > anything else; and, of course, easily be reenabled if needed,
> > without much process either.
> 
> Aye, that's the key concept behind adding an explicit "Dormant" status
> for core developers - they're folks that are still trusted with core
> commit privileges if they choose to exercise them, but while they're
> not using their access, it's better to deactivate their credentials to
> reduce the potential for compromise.
> 
> We'd add a note to the developer guide that gave instructions on how
> to request reactivation (likely just "Check the developer guide to
> ensure you're up to speed with any changes since you were last active,
> then past to python-committers requesting that your credentials be
> reactivated").
> 
> Right, no one's role of having been a core dev will be wiped from history, they just won't have the core dev logo next to their bugs.python.org <http://bugs.python.org/> username in the issue tracker (which if they are so dormant to have not added their GitHub username then  they probably don't care about that anyway ;) . And flipping everything back on is a radio button and a word in bugs.python.org <http://bugs.python.org/> if their triage rights are removed and clicking on a button on a web page on GitHub if we clean up for dev access on the repository.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers <https://mail.python.org/mailman/listinfo/python-committers>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/2ea4300a/attachment.html>

From guido at python.org  Mon Jun 18 15:30:29 2018
From: guido at python.org (Guido van Rossum)
Date: Mon, 18 Jun 2018 12:30:29 -0700
Subject: [python-committers] Changing commiter status (was: Missing In
 Action)
In-Reply-To: <CFFB98A1-2CCB-4D37-858F-939E6852C696@cwi.nl>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <CFFB98A1-2CCB-4D37-858F-939E6852C696@cwi.nl>
Message-ID: <CAP7+vJ+VancUUYGOxUp603XpqkoQXroWdR2tzodRVPfpq9Ng8Q@mail.gmail.com>

I propose "emeritus core dev". It's a word that conveys *extra* status.

On Mon, Jun 18, 2018 at 12:24 PM Jack Jansen <jack.jansen at cwi.nl> wrote:

> I know that this is the case for me.
>
> I wouldn?t _dream_ of committing anything (after 10 years or so) without
> first consulting with current core developers, etc. But formally being a
> Python core dev does give me status with my colleagues, students, children
> (well, one only), nephews and nieces, etc. and I have just enough vanity to
> kind of enjoy that. Just the other day a nephew took a selfie of the two of
> us and posted it to all friends, YES! :-)
>
> That said: I would fully understand if my status was changed to ?dormant
> core dev? or ?retired core dev? and I wouldn?t have any problems with that.
>
> Jack
>
>
> On  18-Jun-2018, at 21:07 , Guido van Rossum <guido at python.org> wrote:
>
> Hm, unless I misunderstood, MAL's
>
> > Being a core developer of Python is a status
>
> suggests that core devs might want to keep this status since it confers
> "status" on their person (it looks good on a resume for sure). And I
> wouldn't want to make it any harder for a 3rd party to verify someone's
> claim to this status in their resume.
>
> Marc-Andre, is that what you meant?
>
> On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett at python.org> wrote:
>
>>
>>
>> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 18 June 2018 at 18:07, M.-A. Lemburg <mal at egenix.com> wrote:
>>> > Overall, I think that removing repo or bpo permissions should be
>>> > kept separate from the status itself. It would probably be wise
>>> > to send around reminders to all core devs who have access and
>>> > have not used their permissions every few year. The keys of those
>>> > who don't respond could then be disabled, without affecting
>>> > anything else; and, of course, easily be reenabled if needed,
>>> > without much process either.
>>>
>>> Aye, that's the key concept behind adding an explicit "Dormant" status
>>> for core developers - they're folks that are still trusted with core
>>> commit privileges if they choose to exercise them, but while they're
>>> not using their access, it's better to deactivate their credentials to
>>> reduce the potential for compromise.
>>>
>>> We'd add a note to the developer guide that gave instructions on how
>>> to request reactivation (likely just "Check the developer guide to
>>> ensure you're up to speed with any changes since you were last active,
>>> then past to python-committers requesting that your credentials be
>>> reactivated").
>>>
>>
>> Right, no one's role of having been a core dev will be wiped from
>> history, they just won't have the core dev logo next to their
>> bugs.python.org username in the issue tracker (which if they are so
>> dormant to have not added their GitHub username then  they probably don't
>> care about that anyway ;) . And flipping everything back on is a radio
>> button and a word in bugs.python.org if their triage rights are removed
>> and clicking on a button on a web page on GitHub if we clean up for dev
>> access on the repository.
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
> --
>
> Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
>
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
>

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/6718692a/attachment-0001.html>

From mal at egenix.com  Mon Jun 18 15:41:49 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 18 Jun 2018 21:41:49 +0200
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
Message-ID: <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>

On 18.06.2018 21:07, Guido van Rossum wrote:
> Hm, unless I misunderstood, MAL's
> 
>> Being a core developer of Python is a status
> 
> suggests that core devs might want to keep this status since it confers
> "status" on their person (it looks good on a resume for sure). And I
> wouldn't want to make it any harder for a 3rd party to verify someone's
> claim to this status in their resume.
> 
> Marc-Andre, is that what you meant?

I guess I wasn't clear, sorry.

Perhaps the better term is "title" rather than "status". My
understanding is that you become core developer and essentially
keep this title forever.

Whether you actually have your keys in the repo to push a PR
or not is a different story and not really related to the "title"
you earned.

Listing the core developers somewhere on an official page
would help with the verification you are referring to. At
the moment, we don't seem to have this. It does make a difference
on CVs and it's one of the few things we can give back to people
when contributing code and time to Python.

Hope that's a little clearer.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts
>>> 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/


> On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett at python.org> wrote:
> 
>>
>>
>> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 18 June 2018 at 18:07, M.-A. Lemburg <mal at egenix.com> wrote:
>>>> Overall, I think that removing repo or bpo permissions should be
>>>> kept separate from the status itself. It would probably be wise
>>>> to send around reminders to all core devs who have access and
>>>> have not used their permissions every few year. The keys of those
>>>> who don't respond could then be disabled, without affecting
>>>> anything else; and, of course, easily be reenabled if needed,
>>>> without much process either.
>>>
>>> Aye, that's the key concept behind adding an explicit "Dormant" status
>>> for core developers - they're folks that are still trusted with core
>>> commit privileges if they choose to exercise them, but while they're
>>> not using their access, it's better to deactivate their credentials to
>>> reduce the potential for compromise.
>>>
>>> We'd add a note to the developer guide that gave instructions on how
>>> to request reactivation (likely just "Check the developer guide to
>>> ensure you're up to speed with any changes since you were last active,
>>> then past to python-committers requesting that your credentials be
>>> reactivated").
>>>
>>
>> Right, no one's role of having been a core dev will be wiped from history,
>> they just won't have the core dev logo next to their bugs.python.org
>> username in the issue tracker (which if they are so dormant to have not
>> added their GitHub username then  they probably don't care about that
>> anyway ;) . And flipping everything back on is a radio button and a word in
>> bugs.python.org if their triage rights are removed and clicking on a
>> button on a web page on GitHub if we clean up for dev access on the
>> repository.
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> 
> 


From tjreedy at udel.edu  Mon Jun 18 15:57:20 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 18 Jun 2018 15:57:20 -0400
Subject: [python-committers] Changing commiter status
In-Reply-To: <CFFB98A1-2CCB-4D37-858F-939E6852C696@cwi.nl>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <CFFB98A1-2CCB-4D37-858F-939E6852C696@cwi.nl>
Message-ID: <469e4f7d-1f7c-1bf2-bf4e-5340e6913a2e@udel.edu>

On 6/18/2018 3:24 PM, Jack Jansen wrote:
> I know that this is the case for me.
> 
> I wouldn?t _dream_ of committing anything (after 10 years or so) without 
> first consulting with current core developers, etc.

We would, of course, help you get back up to speed with the current 
workflow, if you wished.  You could even start by reviewing a few PRs 
before merging one yourself.

tjr



From tjreedy at udel.edu  Mon Jun 18 16:48:32 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 18 Jun 2018 16:48:32 -0400
Subject: [python-committers] Vote to promote Pablo Salingo Salgado as
 core developer
In-Reply-To: <CAP1=2W7sKDr6jGTWjWV0r46j_pUeDSns41261Kj6hyZvfoi3Ww@mail.gmail.com>
References: <CA+3bQGFhWvtJjwni1hkSkfjUYbkzxQdG2_SFpgws1MozrZOQgg@mail.gmail.com>
 <6604776e-a339-6c36-1311-edcd777c0104@udel.edu>
 <c9ed730e-a0c6-a4ca-e298-8daa185f7843@gmail.com>
 <CA+3bQGHXoGG1+s+Y-YMB5s-xnPqfa8QG=wsLW9M4HC+XWfMoqQ@mail.gmail.com>
 <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com>
 <d9b83569-8cf1-fc3f-7158-b4354e1e32b8@udel.edu>
 <70684ccd-8a3d-50f9-7509-5ad8ddf9d91b@python.org>
 <CAP1=2W7sKDr6jGTWjWV0r46j_pUeDSns41261Kj6hyZvfoi3Ww@mail.gmail.com>
Message-ID: <71f5e9fc-c478-f415-dac8-33627aaaa184@udel.edu>

On 6/18/2018 2:37 PM, Brett Cannon wrote:
> 
> 
> On Mon, 18 Jun 2018 at 11:17 Antoine Pitrou <antoine at python.org 
> <mailto:antoine at python.org>> wrote:
> 
> 
>     Le 14/06/2018 ? 04:30, Terry Reedy a ?crit?:
>      > On 6/13/2018 7:03 PM, Carol Willing wrote:
>      >> +1 With Victor's mentoring (1 or 2 months), I believe that it is
>      >> reasonable to promote Pablo to a core developer either now or
>     after 3
>      >> months of coaching.
>      >>
>      >> I would also like to see Cheryl Sabella who has been very active
>     on the
>      >> bug tracker to also be promoted to a core developer.
>      >
>      > A bit off topic, but I would too, as she has been extremely
>     helpful with
>      > IDLE.
> 
>     It's very nice that we're getting new active contributors.
>     OTOH if Cheryl is mostly active on the bug tracker, does she need commit
>     rights in order to participate properly?

On the tracker, ordinary commit rights add the little symbol after your 
name and add your name to the drop down lists for Assigned and Nosy. 
(The latter, by the way, would be a reason to de-activate people 
inactive after several years.)

>? Or did she also review PRs or submit some of her own?

In the last year, she has submitted roughly 70 PRs, about half for IDLE, 
and perhaps 2/3 have been merged.  I still need to review her remaining 
IDLE PRs.  The last few I merged with little or no changed.  She has 
done some reviews, especially when asked, but obviously prefers writing.

On Github, the main effects of commits rights are addition to the list 
of possible reviewers, more weight to reviews (as far as github is 
concerned), and the possibility of pushing changes to both the PR branch 
and cpython.

> Cheryl is actually the 6th most active contributor by commits over the 
> past year: 
> https://github.com/python/cpython/graphs/contributors?from=2017-06-18&to=2018-06-18&type=c 
> (IOW only Victor, you, Yury, Terry, and Ned have more commits since 
> 2017-06-18).



From p.f.moore at gmail.com  Mon Jun 18 16:52:21 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 18 Jun 2018 21:52:21 +0100
Subject: [python-committers] Changing commiter status
In-Reply-To: <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
Message-ID: <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>

On 18 June 2018 at 20:41, M.-A. Lemburg <mal at egenix.com> wrote:
> On 18.06.2018 21:07, Guido van Rossum wrote:
>> Hm, unless I misunderstood, MAL's
>>
>>> Being a core developer of Python is a status
>>
>> suggests that core devs might want to keep this status since it confers
>> "status" on their person (it looks good on a resume for sure). And I
>> wouldn't want to make it any harder for a 3rd party to verify someone's
>> claim to this status in their resume.
>>
>> Marc-Andre, is that what you meant?
>
> I guess I wasn't clear, sorry.
>
> Perhaps the better term is "title" rather than "status". My
> understanding is that you become core developer and essentially
> keep this title forever.
>
> Whether you actually have your keys in the repo to push a PR
> or not is a different story and not really related to the "title"
> you earned.
>
> Listing the core developers somewhere on an official page
> would help with the verification you are referring to. At
> the moment, we don't seem to have this. It does make a difference
> on CVs and it's one of the few things we can give back to people
> when contributing code and time to Python.

Just to add my thoughts here. I agree that "being a Python core
developer" is something people can be proud of (I know I am!), as well
as being good to put on a CV. It would be a shame to devalue that
pride by saying in effect that you're no longer a "real" core
developer if you don't keep contributing.

So I'd very much like to distinguish the idea of "being a core
developer" from the administrative management of commit privileges.
The respect and gratitude of our peers is one of the few things it's
possible to get as a reward for open source contributions - let's be
generous with that (and with openly acknowledging it).

Paul

From chris.jerdonek at gmail.com  Mon Jun 18 20:20:40 2018
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Mon, 18 Jun 2018 17:20:40 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
Message-ID: <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>

What will be the threshold of activity? For example, if one hasn?t been
committing due to time but occasionally comments on or opens b.p.o. issues
or reviews pull requests, etc, would that mean the logo disappears? There
is value in having the logo show up when commenting.

?Chris

On Mon, Jun 18, 2018 at 1:52 PM Paul Moore <p.f.moore at gmail.com> wrote:

> On 18 June 2018 at 20:41, M.-A. Lemburg <mal at egenix.com> wrote:
> > On 18.06.2018 21:07, Guido van Rossum wrote:
> >> Hm, unless I misunderstood, MAL's
> >>
> >>> Being a core developer of Python is a status
> >>
> >> suggests that core devs might want to keep this status since it confers
> >> "status" on their person (it looks good on a resume for sure). And I
> >> wouldn't want to make it any harder for a 3rd party to verify someone's
> >> claim to this status in their resume.
> >>
> >> Marc-Andre, is that what you meant?
> >
> > I guess I wasn't clear, sorry.
> >
> > Perhaps the better term is "title" rather than "status". My
> > understanding is that you become core developer and essentially
> > keep this title forever.
> >
> > Whether you actually have your keys in the repo to push a PR
> > or not is a different story and not really related to the "title"
> > you earned.
> >
> > Listing the core developers somewhere on an official page
> > would help with the verification you are referring to. At
> > the moment, we don't seem to have this. It does make a difference
> > on CVs and it's one of the few things we can give back to people
> > when contributing code and time to Python.
>
> Just to add my thoughts here. I agree that "being a Python core
> developer" is something people can be proud of (I know I am!), as well
> as being good to put on a CV. It would be a shame to devalue that
> pride by saying in effect that you're no longer a "real" core
> developer if you don't keep contributing.
>
> So I'd very much like to distinguish the idea of "being a core
> developer" from the administrative management of commit privileges.
> The respect and gratitude of our peers is one of the few things it's
> possible to get as a reward for open source contributions - let's be
> generous with that (and with openly acknowledging it).
>
> Paul
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/c0511319/attachment.html>

From guido at python.org  Mon Jun 18 20:54:41 2018
From: guido at python.org (Guido van Rossum)
Date: Mon, 18 Jun 2018 17:54:41 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
Message-ID: <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>

I'd do it as follows. This basically makes withdrawal voluntary unless they
don't respond at all.

1. Make a list of people who've not shown any sign of activity (on the
b.p.o. or GitHub, as reviewer or committer) for at least one year.
2. Email all of them, asking if they still want to be a core dev. Choices
could include
  a. Yes
  b. Keep the logo and b.p.o. access but disable GitHub key
  c. Drop everything
3. If someone doesn't respond despite repeated attempts (maybe using
different email addresses or social media) then after 4 weeks assume they
meant to answer (c). But if they write back later they can be restored
according to their preference (a, b, c), no questions asked.

If we currently have a list of core devs we should by default change
people's status to emeritus core dev when they choose (c). They may also
choose to be removed from such a list. But I don't know if we have a list.


On Mon, Jun 18, 2018 at 5:21 PM Chris Jerdonek <chris.jerdonek at gmail.com>
wrote:

> What will be the threshold of activity? For example, if one hasn?t been
> committing due to time but occasionally comments on or opens b.p.o. issues
> or reviews pull requests, etc, would that mean the logo disappears? There
> is value in having the logo show up when commenting.
>
> ?Chris
>
> On Mon, Jun 18, 2018 at 1:52 PM Paul Moore <p.f.moore at gmail.com> wrote:
>
>> On 18 June 2018 at 20:41, M.-A. Lemburg <mal at egenix.com> wrote:
>> > On 18.06.2018 21:07, Guido van Rossum wrote:
>> >> Hm, unless I misunderstood, MAL's
>> >>
>> >>> Being a core developer of Python is a status
>> >>
>> >> suggests that core devs might want to keep this status since it confers
>> >> "status" on their person (it looks good on a resume for sure). And I
>> >> wouldn't want to make it any harder for a 3rd party to verify someone's
>> >> claim to this status in their resume.
>> >>
>> >> Marc-Andre, is that what you meant?
>> >
>> > I guess I wasn't clear, sorry.
>> >
>> > Perhaps the better term is "title" rather than "status". My
>> > understanding is that you become core developer and essentially
>> > keep this title forever.
>> >
>> > Whether you actually have your keys in the repo to push a PR
>> > or not is a different story and not really related to the "title"
>> > you earned.
>> >
>> > Listing the core developers somewhere on an official page
>> > would help with the verification you are referring to. At
>> > the moment, we don't seem to have this. It does make a difference
>> > on CVs and it's one of the few things we can give back to people
>> > when contributing code and time to Python.
>>
>> Just to add my thoughts here. I agree that "being a Python core
>> developer" is something people can be proud of (I know I am!), as well
>> as being good to put on a CV. It would be a shame to devalue that
>> pride by saying in effect that you're no longer a "real" core
>> developer if you don't keep contributing.
>>
>> So I'd very much like to distinguish the idea of "being a core
>> developer" from the administrative management of commit privileges.
>> The respect and gratitude of our peers is one of the few things it's
>> possible to get as a reward for open source contributions - let's be
>> generous with that (and with openly acknowledging it).
>>
>> Paul
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/1b51e78e/attachment.html>

From taleinat at gmail.com  Tue Jun 19 01:12:23 2018
From: taleinat at gmail.com (Tal Einat)
Date: Tue, 19 Jun 2018 08:12:23 +0300
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
Message-ID: <CALWZvp4dSOdbjq=7_27rNDBpqj7memwnGFP1gNmbmf6rz+e__w@mail.gmail.com>

On Tue, Jun 19, 2018 at 3:54 AM, Guido van Rossum <guido at python.org> wrote:
>
> If we currently have a list of core devs we should by default change people's status to emeritus core dev when they choose (c). They may also choose to be removed from such a list. But I don't know if we have a list.

We have at least one list on the developers' guide:
https://devguide.python.org/developers/

It's more of a log of permissions granted and dropped. It also has a
section titled "Permissions Dropped after Loss of Contact", currently
with a single entry.

- Tal Einat

From brett at python.org  Tue Jun 19 12:39:56 2018
From: brett at python.org (Brett Cannon)
Date: Tue, 19 Jun 2018 09:39:56 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
Message-ID: <CAP1=2W5On4PM-YTaEpXkU6Nd-tf_vLCpmpnpq5qy-daq_v1gAg@mail.gmail.com>

On Mon, 18 Jun 2018 at 12:41 M.-A. Lemburg <mal at egenix.com> wrote:

> On 18.06.2018 21:07, Guido van Rossum wrote:
> > Hm, unless I misunderstood, MAL's
> >
> >> Being a core developer of Python is a status
> >
> > suggests that core devs might want to keep this status since it confers
> > "status" on their person (it looks good on a resume for sure). And I
> > wouldn't want to make it any harder for a 3rd party to verify someone's
> > claim to this status in their resume.
> >
> > Marc-Andre, is that what you meant?
>
> I guess I wasn't clear, sorry.
>
> Perhaps the better term is "title" rather than "status". My
> understanding is that you become core developer and essentially
> keep this title forever.
>
> Whether you actually have your keys in the repo to push a PR
> or not is a different story and not really related to the "title"
> you earned.
>
> Listing the core developers somewhere on an official page
> would help with the verification you are referring to. At
> the moment, we don't seem to have this. It does make a difference
> on CVs and it's one of the few things we can give back to people
> when contributing code and time to Python.
>
> Hope that's a little clearer.
>

Yep, and no one is suggesting you don't get listed as a core dev somewhere.
Basically the idea is you would swap the Python logo next to your name on
bugs.python.org to being listed on a page on devguide.python.org in terms
of visibly being identified as a core dev.

-Brett


>
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts
> >>> 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/
>
>
> > On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett at python.org> wrote:
> >
> >>
> >>
> >> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>
> >>> On 18 June 2018 at 18:07, M.-A. Lemburg <mal at egenix.com> wrote:
> >>>> Overall, I think that removing repo or bpo permissions should be
> >>>> kept separate from the status itself. It would probably be wise
> >>>> to send around reminders to all core devs who have access and
> >>>> have not used their permissions every few year. The keys of those
> >>>> who don't respond could then be disabled, without affecting
> >>>> anything else; and, of course, easily be reenabled if needed,
> >>>> without much process either.
> >>>
> >>> Aye, that's the key concept behind adding an explicit "Dormant" status
> >>> for core developers - they're folks that are still trusted with core
> >>> commit privileges if they choose to exercise them, but while they're
> >>> not using their access, it's better to deactivate their credentials to
> >>> reduce the potential for compromise.
> >>>
> >>> We'd add a note to the developer guide that gave instructions on how
> >>> to request reactivation (likely just "Check the developer guide to
> >>> ensure you're up to speed with any changes since you were last active,
> >>> then past to python-committers requesting that your credentials be
> >>> reactivated").
> >>>
> >>
> >> Right, no one's role of having been a core dev will be wiped from
> history,
> >> they just won't have the core dev logo next to their bugs.python.org
> >> username in the issue tracker (which if they are so dormant to have not
> >> added their GitHub username then  they probably don't care about that
> >> anyway ;) . And flipping everything back on is a radio button and a
> word in
> >> bugs.python.org if their triage rights are removed and clicking on a
> >> button on a web page on GitHub if we clean up for dev access on the
> >> repository.
> >> _______________________________________________
> >> python-committers mailing list
> >> python-committers at python.org
> >> https://mail.python.org/mailman/listinfo/python-committers
> >> Code of Conduct: https://www.python.org/psf/codeofconduct/
> >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/e0f07461/attachment.html>

From guido at python.org  Tue Jun 19 13:13:33 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 19 Jun 2018 10:13:33 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <CALWZvp4dSOdbjq=7_27rNDBpqj7memwnGFP1gNmbmf6rz+e__w@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
 <CALWZvp4dSOdbjq=7_27rNDBpqj7memwnGFP1gNmbmf6rz+e__w@mail.gmail.com>
Message-ID: <CAP7+vJKfaOD65ioVe04XF4Rh2LctM84A2vtCfS0ejek_dwrJTQ@mail.gmail.com>

On Mon, Jun 18, 2018 at 10:12 PM Tal Einat <taleinat at gmail.com> wrote:

> On Tue, Jun 19, 2018 at 3:54 AM, Guido van Rossum <guido at python.org>
> wrote:
> >
> > If we currently have a list of core devs we should by default change
> people's status to emeritus core dev when they choose (c). They may also
> choose to be removed from such a list. But I don't know if we have a list.
>
> We have at least one list on the developers' guide:
> https://devguide.python.org/developers/
>
> It's more of a log of permissions granted and dropped. It also has a
> section titled "Permissions Dropped after Loss of Contact", currently
> with a single entry.
>

Hm, yeah, and it's incomplete (original developers like Jack are not listed
at all). The UX of the tree separate reverse-chronologically ordered lists
is also debatable: I'd have two lists, current core devs (with a record of
when and by whom they were given permissions, as the current list) and
emeritus core devs (with the same record, plus a record of when and why
their permission was dropped).

On the plus side, I spent a minute of nostalgia while perusing the older
entries...

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/b58a7be6/attachment.html>

From vstinner at redhat.com  Tue Jun 19 13:35:41 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 19 Jun 2018 19:35:41 +0200
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
Message-ID: <CA+3bQGFYrEiHsDQWyT6UrHf1PPSYvppsmHQXVn_tcH5d15RnuQ@mail.gmail.com>

2018-06-19 2:54 GMT+02:00 Guido van Rossum <guido at python.org>:
> I'd do it as follows. This basically makes withdrawal voluntary unless they
> don't respond at all.
>
> 1. Make a list of people who've not shown any sign of activity (on the
> b.p.o. or GitHub, as reviewer or committer) for at least one year.
> 2. Email all of them, asking if they still want to be a core dev. Choices
> could include
>   a. Yes
>   b. Keep the logo and b.p.o. access but disable GitHub key
>   c. Drop everything
> 3. If someone doesn't respond despite repeated attempts (maybe using
> different email addresses or social media) then after 4 weeks assume they
> meant to answer (c). But if they write back later they can be restored
> according to their preference (a, b, c), no questions asked.
>
> If we currently have a list of core devs we should by default change
> people's status to emeritus core dev when they choose (c). They may also
> choose to be removed from such a list. But I don't know if we have a list.

Question about "emeritus".

My intent is to maintain a list of active core developers. If an
inactive core dev becomes active again, they should be able to
retrieve quickly the "active" status. Is "emeritus" still a good name
with such constraint?

Note: I like "emeritus" name to describe inactive core devs ;-)

Victor

From donald at stufft.io  Tue Jun 19 13:38:41 2018
From: donald at stufft.io (Donald Stufft)
Date: Tue, 19 Jun 2018 13:38:41 -0400
Subject: [python-committers] Changing commiter status
In-Reply-To: <CA+3bQGFYrEiHsDQWyT6UrHf1PPSYvppsmHQXVn_tcH5d15RnuQ@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
 <CA+3bQGFYrEiHsDQWyT6UrHf1PPSYvppsmHQXVn_tcH5d15RnuQ@mail.gmail.com>
Message-ID: <8E52FB33-6014-4E2F-9FF9-837CB3A41730@stufft.io>



> On Jun 19, 2018, at 1:35 PM, Victor Stinner <vstinner at redhat.com> wrote:
> 
> My intent is to maintain a list of active core developers. If an
> inactive core dev becomes active again, they should be able to
> retrieve quickly the "active" status. Is "emeritus" still a good name
> with such constraint?


Yes. Dropping the permission bits of inactive developers really only works if those developers can more or less no questions asked get those permissions back whenever they want them. Otherwise it?s not really a ?we?re just trimming permission lists for security? thing anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/bc5d5861/attachment.html>

From vstinner at redhat.com  Tue Jun 19 13:43:13 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 19 Jun 2018 19:43:13 +0200
Subject: [python-committers] Results of Pablo's promotion votes: Pablo is
 promoted as a core dev!
Message-ID: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>

Hi,

The result of the vote to to promote Pablo Salingo Salgado as core developer
after one week is positive: I declare that Pablo is now a core developer,
congrats! I will follow the usual process to actually make him a core dev,
and ask him to write a short introduction email to this list.

But I also noted that Pablo lacks experience to be fully autonomous on merging
pull requests, so I also requires that Pablo will have to be strictly mentored
by me for 3 months. By strict, I mean that Pablo will have to ask me to
merge any pull request. This strict mentoring may be extended depending on
Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to
blame me directly if anything goes wrong :-)

Giving more responsibilities to Pablo is part of the learning process.
Reviewing as a core developer is different than a review as a contributor: core
developers are expected to actually merge a pull request once they approve the
change. Merging a pull request is a big responsibility and an investment in
the long-term, because the committer is expected to fix regressions and issues
related to this change for next months, if not next years.

Note: Cheryl Sabella has also been identified as an active contributor who may
be promoted as well. I am already discussing with her about that for 1 month,
but last month, Cheryl chose to wait. I will keep you in touch ;-)

Vote results.

Promote (+1): 8 votes

* Victor Stinner
* Terry Reedy
* Carol Willing
* Gregory P. Smith ("+0.5")
* Eric Snow
* Brett Cannon
* Nathaniel Smith
* Antoine Pitrou ("+0.5")

Wait (-1): 1 vote

* Berker Peksa?

Neutral (0): 1 vote

* Serhiy Storchaka ("-0")

Victor

From mal at egenix.com  Tue Jun 19 14:14:45 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 19 Jun 2018 20:14:45 +0200
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAP1=2W5On4PM-YTaEpXkU6Nd-tf_vLCpmpnpq5qy-daq_v1gAg@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CAP1=2W5On4PM-YTaEpXkU6Nd-tf_vLCpmpnpq5qy-daq_v1gAg@mail.gmail.com>
Message-ID: <d911cb0c-ef29-0af1-0bc7-1e82867f4261@egenix.com>

On 19.06.2018 18:39, Brett Cannon wrote:
> On Mon, 18 Jun 2018 at 12:41 M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 18.06.2018 21:07, Guido van Rossum wrote:
>>> Hm, unless I misunderstood, MAL's
>>>
>>>> Being a core developer of Python is a status
>>>
>>> suggests that core devs might want to keep this status since it confers
>>> "status" on their person (it looks good on a resume for sure). And I
>>> wouldn't want to make it any harder for a 3rd party to verify someone's
>>> claim to this status in their resume.
>>>
>>> Marc-Andre, is that what you meant?
>>
>> I guess I wasn't clear, sorry.
>>
>> Perhaps the better term is "title" rather than "status". My
>> understanding is that you become core developer and essentially
>> keep this title forever.
>>
>> Whether you actually have your keys in the repo to push a PR
>> or not is a different story and not really related to the "title"
>> you earned.
>>
>> Listing the core developers somewhere on an official page
>> would help with the verification you are referring to. At
>> the moment, we don't seem to have this. It does make a difference
>> on CVs and it's one of the few things we can give back to people
>> when contributing code and time to Python.
>>
>> Hope that's a little clearer.
>>
> 
> Yep, and no one is suggesting you don't get listed as a core dev somewhere.
> Basically the idea is you would swap the Python logo next to your name on
> bugs.python.org to being listed on a page on devguide.python.org in terms
> of visibly being identified as a core dev.

I personally would not want that to happen, since while I
don't have time to contribute code anymore, I still do
comment on tickets.

Ok, let me be even clearer :-)

While I understand that there is a need to show the world that
we need more active core devs, this drive to shelve existing
developers is not a good way to achieve this.

Here's a simple approach which is effective without all the
implied social costs of removing core dev flags:

* create a page with the core devs who have at least 10 commits
  in the last 6 months (the "active" ones):


https://github.com/python/cpython/graphs/contributors?from=2017-12-19&to=2018-06-19&type=c

  (at the moment, this gives 21 entries)

* run a few posts calling for help, pointing people to ways
  of becoming a core developers, the mentoring program,
  sprints to attend, etc.

* create a page listing the core developers to show the world
  who we are and add value to the title in order to make it
  interesting for other developers to get on that page as well

* perhaps also mention some other forms of recognition
  such as Mike's Python Dev of the Week:
  https://www.blog.pythonlibrary.org/category/pydevoftheweek/

* add more ways to add recognition to the core dev title
  to make it more attractive, e.g. an free tickets to PyCon US
  for life, your own page on python.org, etc.

We need to put some carrots out there, and keep refreshing
them.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jun 19 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/


From brett at python.org  Tue Jun 19 14:17:31 2018
From: brett at python.org (Brett Cannon)
Date: Tue, 19 Jun 2018 11:17:31 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
Message-ID: <CAP1=2W5nmB=O6op-AkTLpQbe5gFy7rnWdaLn-7V21=+=86zMvg@mail.gmail.com>

On Mon, 18 Jun 2018 at 17:56 Guido van Rossum <guido at python.org> wrote:

> I'd do it as follows. This basically makes withdrawal voluntary unless
> they don't respond at all.
>
> 1. Make a list of people who've not shown any sign of activity (on the
> b.p.o. or GitHub, as reviewer or committer) for at least one year.
> 2. Email all of them, asking if they still want to be a core dev. Choices
> could include
>   a. Yes
>   b. Keep the logo and b.p.o. access but disable GitHub key
>   c. Drop everything
> 3. If someone doesn't respond despite repeated attempts (maybe using
> different email addresses or social media) then after 4 weeks assume they
> meant to answer (c). But if they write back later they can be restored
> according to their preference (a, b, c), no questions asked.
>

One point I want to make about this pull approach versus a push one is this
is going to be a lot of work. :) For the "no GitHub username" situation on
bugs.python.org there are 80 people to reach out to. For people with commit
rights who have not committed in the past year to CPython (because that's
the best data point I have without writing custom code to find out who has
commented on a PR recently), that would require reaching out to an
additional 50 people. So we're looking at potentially up to 130 people to
try and track down.


>
> If we currently have a list of core devs we should by default change
> people's status to emeritus core dev when they choose (c). They may also
> choose to be removed from such a list. But I don't know if we have a list.
>

We can make a complete list as people seem to want that and have it be
active versus emeritus and list the year people got their commit rights.

Here's a counter-proposal so we can figure out what middle ground we are
all happy with. The developer log gets rewritten to be simpler to just be
two lists: a chronological one of active core devs sorted by when they got
commit privileges, and an alphabetized list of core devs who are now
emeritus (listing their years of service to the project).

The lists start with everyone who has committed to CPython, the devguide,
or the peps repo in the past year as active. Everyone else is listed as
emeritus. People are then given some window -- a month? -- to update
themselves in those lists from emeritus to active. At the end of that month
whomever is still listed as emeritus we turn off their commit access and
b.p.o extras. We announce this here, python-dev, social media, etc. IOW
this becomes more opt-in/push than opt-out/pull.

-Brett


>
>
> On Mon, Jun 18, 2018 at 5:21 PM Chris Jerdonek <chris.jerdonek at gmail.com>
> wrote:
>
>> What will be the threshold of activity? For example, if one hasn?t been
>> committing due to time but occasionally comments on or opens b.p.o. issues
>> or reviews pull requests, etc, would that mean the logo disappears? There
>> is value in having the logo show up when commenting.
>>
>> ?Chris
>>
>> On Mon, Jun 18, 2018 at 1:52 PM Paul Moore <p.f.moore at gmail.com> wrote:
>>
>>> On 18 June 2018 at 20:41, M.-A. Lemburg <mal at egenix.com> wrote:
>>> > On 18.06.2018 21:07, Guido van Rossum wrote:
>>> >> Hm, unless I misunderstood, MAL's
>>> >>
>>> >>> Being a core developer of Python is a status
>>> >>
>>> >> suggests that core devs might want to keep this status since it
>>> confers
>>> >> "status" on their person (it looks good on a resume for sure). And I
>>> >> wouldn't want to make it any harder for a 3rd party to verify
>>> someone's
>>> >> claim to this status in their resume.
>>> >>
>>> >> Marc-Andre, is that what you meant?
>>> >
>>> > I guess I wasn't clear, sorry.
>>> >
>>> > Perhaps the better term is "title" rather than "status". My
>>> > understanding is that you become core developer and essentially
>>> > keep this title forever.
>>> >
>>> > Whether you actually have your keys in the repo to push a PR
>>> > or not is a different story and not really related to the "title"
>>> > you earned.
>>> >
>>> > Listing the core developers somewhere on an official page
>>> > would help with the verification you are referring to. At
>>> > the moment, we don't seem to have this. It does make a difference
>>> > on CVs and it's one of the few things we can give back to people
>>> > when contributing code and time to Python.
>>>
>>> Just to add my thoughts here. I agree that "being a Python core
>>> developer" is something people can be proud of (I know I am!), as well
>>> as being good to put on a CV. It would be a shame to devalue that
>>> pride by saying in effect that you're no longer a "real" core
>>> developer if you don't keep contributing.
>>>
>>> So I'd very much like to distinguish the idea of "being a core
>>> developer" from the administrative management of commit privileges.
>>> The respect and gratitude of our peers is one of the few things it's
>>> possible to get as a reward for open source contributions - let's be
>>> generous with that (and with openly acknowledging it).
>>>
>>> Paul
>>> _______________________________________________
>>> python-committers mailing list
>>> python-committers at python.org
>>> https://mail.python.org/mailman/listinfo/python-committers
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/2e48ebbd/attachment-0001.html>

From guido at python.org  Tue Jun 19 14:30:37 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 19 Jun 2018 11:30:37 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAP1=2W5nmB=O6op-AkTLpQbe5gFy7rnWdaLn-7V21=+=86zMvg@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
 <CAP1=2W5nmB=O6op-AkTLpQbe5gFy7rnWdaLn-7V21=+=86zMvg@mail.gmail.com>
Message-ID: <CAP7+vJJkMX9Y0oOWaGMedY1dyUEbmiA05Hk=BJQ+s8DO1-ASoA@mail.gmail.com>

I honestly have very little stake in this -- the minimum that I'd like to
see is that unused GitHub permissions be revoked to reduce the risk when a
dormant core dev is compromised. (Though if they contribute regularly to
*other* GitHub projects even that risk seems minimal.)

On Tue, Jun 19, 2018 at 11:23 AM Brett Cannon <brett at python.org> wrote:

>
>
> On Mon, 18 Jun 2018 at 17:56 Guido van Rossum <guido at python.org> wrote:
>
>> I'd do it as follows. This basically makes withdrawal voluntary unless
>> they don't respond at all.
>>
>> 1. Make a list of people who've not shown any sign of activity (on the
>> b.p.o. or GitHub, as reviewer or committer) for at least one year.
>> 2. Email all of them, asking if they still want to be a core dev. Choices
>> could include
>>   a. Yes
>>   b. Keep the logo and b.p.o. access but disable GitHub key
>>   c. Drop everything
>> 3. If someone doesn't respond despite repeated attempts (maybe using
>> different email addresses or social media) then after 4 weeks assume they
>> meant to answer (c). But if they write back later they can be restored
>> according to their preference (a, b, c), no questions asked.
>>
>
> One point I want to make about this pull approach versus a push one is
> this is going to be a lot of work. :) For the "no GitHub username"
> situation on bugs.python.org there are 80 people to reach out to. For
> people with commit rights who have not committed in the past year to
> CPython (because that's the best data point I have without writing custom
> code to find out who has commented on a PR recently), that would require
> reaching out to an additional 50 people. So we're looking at potentially up
> to 130 people to try and track down.
>
>
>>
>> If we currently have a list of core devs we should by default change
>> people's status to emeritus core dev when they choose (c). They may also
>> choose to be removed from such a list. But I don't know if we have a list.
>>
>
> We can make a complete list as people seem to want that and have it be
> active versus emeritus and list the year people got their commit rights.
>
> Here's a counter-proposal so we can figure out what middle ground we are
> all happy with. The developer log gets rewritten to be simpler to just be
> two lists: a chronological one of active core devs sorted by when they got
> commit privileges, and an alphabetized list of core devs who are now
> emeritus (listing their years of service to the project).
>
> The lists start with everyone who has committed to CPython, the devguide,
> or the peps repo in the past year as active. Everyone else is listed as
> emeritus. People are then given some window -- a month? -- to update
> themselves in those lists from emeritus to active. At the end of that month
> whomever is still listed as emeritus we turn off their commit access and
> b.p.o extras. We announce this here, python-dev, social media, etc. IOW
> this becomes more opt-in/push than opt-out/pull.
>
> -Brett
>
>
>>
>>
>> On Mon, Jun 18, 2018 at 5:21 PM Chris Jerdonek <chris.jerdonek at gmail.com>
>> wrote:
>>
>>> What will be the threshold of activity? For example, if one hasn?t been
>>> committing due to time but occasionally comments on or opens b.p.o. issues
>>> or reviews pull requests, etc, would that mean the logo disappears? There
>>> is value in having the logo show up when commenting.
>>>
>>> ?Chris
>>>
>>> On Mon, Jun 18, 2018 at 1:52 PM Paul Moore <p.f.moore at gmail.com> wrote:
>>>
>>>> On 18 June 2018 at 20:41, M.-A. Lemburg <mal at egenix.com> wrote:
>>>> > On 18.06.2018 21:07, Guido van Rossum wrote:
>>>> >> Hm, unless I misunderstood, MAL's
>>>> >>
>>>> >>> Being a core developer of Python is a status
>>>> >>
>>>> >> suggests that core devs might want to keep this status since it
>>>> confers
>>>> >> "status" on their person (it looks good on a resume for sure). And I
>>>> >> wouldn't want to make it any harder for a 3rd party to verify
>>>> someone's
>>>> >> claim to this status in their resume.
>>>> >>
>>>> >> Marc-Andre, is that what you meant?
>>>> >
>>>> > I guess I wasn't clear, sorry.
>>>> >
>>>> > Perhaps the better term is "title" rather than "status". My
>>>> > understanding is that you become core developer and essentially
>>>> > keep this title forever.
>>>> >
>>>> > Whether you actually have your keys in the repo to push a PR
>>>> > or not is a different story and not really related to the "title"
>>>> > you earned.
>>>> >
>>>> > Listing the core developers somewhere on an official page
>>>> > would help with the verification you are referring to. At
>>>> > the moment, we don't seem to have this. It does make a difference
>>>> > on CVs and it's one of the few things we can give back to people
>>>> > when contributing code and time to Python.
>>>>
>>>> Just to add my thoughts here. I agree that "being a Python core
>>>> developer" is something people can be proud of (I know I am!), as well
>>>> as being good to put on a CV. It would be a shame to devalue that
>>>> pride by saying in effect that you're no longer a "real" core
>>>> developer if you don't keep contributing.
>>>>
>>>> So I'd very much like to distinguish the idea of "being a core
>>>> developer" from the administrative management of commit privileges.
>>>> The respect and gratitude of our peers is one of the few things it's
>>>> possible to get as a reward for open source contributions - let's be
>>>> generous with that (and with openly acknowledging it).
>>>>
>>>> Paul
>>>> _______________________________________________
>>>> python-committers mailing list
>>>> python-committers at python.org
>>>> https://mail.python.org/mailman/listinfo/python-committers
>>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>>
>>> _______________________________________________
>>> python-committers mailing list
>>> python-committers at python.org
>>> https://mail.python.org/mailman/listinfo/python-committers
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/6dfe9d95/attachment.html>

From ethan at stoneleaf.us  Tue Jun 19 15:55:19 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 19 Jun 2018 12:55:19 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAP1=2W5nmB=O6op-AkTLpQbe5gFy7rnWdaLn-7V21=+=86zMvg@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
 <CAP1=2W5nmB=O6op-AkTLpQbe5gFy7rnWdaLn-7V21=+=86zMvg@mail.gmail.com>
Message-ID: <5B295FA7.8040201@stoneleaf.us>

On 06/19/2018 11:17 AM, Brett Cannon wrote:
> On Mon, 18 Jun 2018 at 17:56 Guido van Rossum wrote:

>> I'd do it as follows. This basically makes withdrawal voluntary unless
 >> they don't respond at all.
>>
>> 1. Make a list of people who've not shown any sign of activity (on the
 >> b.p.o. or GitHub, as reviewer or committer) for at least one year.
 >>
>> 2. Email all of them, asking if they still want to be a core dev. Choices
 >> could include
>> ?  a. Yes
>> ?  b. Keep the logo and b.p.o. access but disable GitHub key
>> ?  c. Drop everything
 >>
>> 3. If someone doesn't respond despite repeated attempts (maybe using
 >> different email addresses or social media) then after 4 weeks assume
 >> they meant to answer (c). But if they write back later they can be
 >> restored according to their preference (a, b, c), no questions asked.
>
> One point I want to make about this pull approach versus a push one is this
 > is going to be a lot of work. :) For the "no GitHub username" situation on
 > bugs.python.org <http://bugs.python.org> there are 80 people to reach out
 > to. For people with commit rights who have not committed in the past year
 > to CPython (because that's the best data point I have without writing custom
 > code to find out who has commented on a PR recently), that would require
 > reaching out to an additional 50 people. So we're looking at potentially up
 > to 130 people to try and track down.

I'm happy to do this.

> We can make a complete list as people seem to want that and have it be active
 > versus emeritus and list the year people got their commit rights.

> At the end of that month whomever is still listed as emeritus we turn off
 > their commit access and b.p.o extras. We announce this here, python-dev,
> social media, etc. IOW this becomes more opt-in/push than opt-out/pull.

The problem with this approach as it's one time -- as soon as someone fades away it's once again out of date.

I'll take on the task of contacting the 130 people to get this started, then once a year somebody does the same thing 
with whichever handful of people have gone dormant that year.

Sound fair?

--
~Ethan~


From steve.dower at python.org  Tue Jun 19 16:10:40 2018
From: steve.dower at python.org (Steve Dower)
Date: Tue, 19 Jun 2018 13:10:40 -0700
Subject: [python-committers] Results of Pablo's promotion votes: Pablo
 ispromoted as a core dev!
In-Reply-To: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
References: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
Message-ID: <mailman.20.1529439043.25824.python-committers@python.org>

Not trying to dispute the result (I?d have posted earlier if I was really concerned), but it sounds like you?ve signed up to mentor someone for three months. Under normal circumstances, the commit bit comes at the end of mentorship, not at the start.

Should we promote other mentees as well? I know there are a few who have been deliberately pursuing this recognition (as they attended the language summit and/or were specifically requested to attend the core sprint by their mentors).

Top-posted from my Windows 10 phone

From: Victor Stinner
Sent: Tuesday, June 19, 2018 10:44
To: python-committers
Subject: [python-committers] Results of Pablo's promotion votes: Pablo ispromoted as a core dev!

Hi,

The result of the vote to to promote Pablo Salingo Salgado as core developer
after one week is positive: I declare that Pablo is now a core developer,
congrats! I will follow the usual process to actually make him a core dev,
and ask him to write a short introduction email to this list.

But I also noted that Pablo lacks experience to be fully autonomous on merging
pull requests, so I also requires that Pablo will have to be strictly mentored
by me for 3 months. By strict, I mean that Pablo will have to ask me to
merge any pull request. This strict mentoring may be extended depending on
Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to
blame me directly if anything goes wrong :-)

Giving more responsibilities to Pablo is part of the learning process.
Reviewing as a core developer is different than a review as a contributor: core
developers are expected to actually merge a pull request once they approve the
change. Merging a pull request is a big responsibility and an investment in
the long-term, because the committer is expected to fix regressions and issues
related to this change for next months, if not next years.

Note: Cheryl Sabella has also been identified as an active contributor who may
be promoted as well. I am already discussing with her about that for 1 month,
but last month, Cheryl chose to wait. I will keep you in touch ;-)

Vote results.

Promote (+1): 8 votes

* Victor Stinner
* Terry Reedy
* Carol Willing
* Gregory P. Smith ("+0.5")
* Eric Snow
* Brett Cannon
* Nathaniel Smith
* Antoine Pitrou ("+0.5")

Wait (-1): 1 vote

* Berker Peksa?

Neutral (0): 1 vote

* Serhiy Storchaka ("-0")

Victor
_______________________________________________
python-committers mailing list
python-committers at python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/b0e007d2/attachment.html>

From guido at python.org  Tue Jun 19 16:15:57 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 19 Jun 2018 13:15:57 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <5B295FA7.8040201@stoneleaf.us>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
 <CAP1=2W5nmB=O6op-AkTLpQbe5gFy7rnWdaLn-7V21=+=86zMvg@mail.gmail.com>
 <5B295FA7.8040201@stoneleaf.us>
Message-ID: <CAP7+vJJ8Ebz6bLvimzjoUEA6fsw3wALnRzR3fGngwvxB9R4oOQ@mail.gmail.com>

I'm happy to see you do this. It'll be very interesting what kind of
responses you get. Do you know how to get the list of 130 people? (I don't,
but Mariatta probably has it already.)

On Tue, Jun 19, 2018 at 12:51 PM Ethan Furman <ethan at stoneleaf.us> wrote:

> On 06/19/2018 11:17 AM, Brett Cannon wrote:
> > On Mon, 18 Jun 2018 at 17:56 Guido van Rossum wrote:
>
> >> I'd do it as follows. This basically makes withdrawal voluntary unless
>  >> they don't respond at all.
> >>
> >> 1. Make a list of people who've not shown any sign of activity (on the
>  >> b.p.o. or GitHub, as reviewer or committer) for at least one year.
>  >>
> >> 2. Email all of them, asking if they still want to be a core dev.
> Choices
>  >> could include
> >> ?  a. Yes
> >> ?  b. Keep the logo and b.p.o. access but disable GitHub key
> >> ?  c. Drop everything
>  >>
> >> 3. If someone doesn't respond despite repeated attempts (maybe using
>  >> different email addresses or social media) then after 4 weeks assume
>  >> they meant to answer (c). But if they write back later they can be
>  >> restored according to their preference (a, b, c), no questions asked.
> >
> > One point I want to make about this pull approach versus a push one is
> this
>  > is going to be a lot of work. :) For the "no GitHub username" situation
> on
>  > bugs.python.org <http://bugs.python.org> there are 80 people to reach
> out
>  > to. For people with commit rights who have not committed in the past
> year
>  > to CPython (because that's the best data point I have without writing
> custom
>  > code to find out who has commented on a PR recently), that would require
>  > reaching out to an additional 50 people. So we're looking at
> potentially up
>  > to 130 people to try and track down.
>
> I'm happy to do this.
>
> > We can make a complete list as people seem to want that and have it be
> active
>  > versus emeritus and list the year people got their commit rights.
>
> > At the end of that month whomever is still listed as emeritus we turn off
>  > their commit access and b.p.o extras. We announce this here, python-dev,
> > social media, etc. IOW this becomes more opt-in/push than opt-out/pull.
>
> The problem with this approach as it's one time -- as soon as someone
> fades away it's once again out of date.
>
> I'll take on the task of contacting the 130 people to get this started,
> then once a year somebody does the same thing
> with whichever handful of people have gone dormant that year.
>
> Sound fair?
>
> --
> ~Ethan~
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/25f89e8f/attachment.html>

From guido at python.org  Tue Jun 19 16:18:32 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 19 Jun 2018 13:18:32 -0700
Subject: [python-committers] Results of Pablo's promotion votes: Pablo
 ispromoted as a core dev!
In-Reply-To: <419JxM2dq8zFr22@mail.python.org>
References: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
 <419JxM2dq8zFr22@mail.python.org>
Message-ID: <CAP7+vJ+wUWVKoCVJK=GE+EDyjJ8eMZZV6MJf9hy_1n0YXyX0+A@mail.gmail.com>

I think we should give the mentors a choice in this. Victor has chosen to
do it this way for Pablo. I don't know who (if anyone) is mentoring Cheryl.
I think Eric Snow is mentoring Emily (I am too, but my mentoring is not
very hands-on, and we only chat once every 3 weeks at most.)

On Tue, Jun 19, 2018 at 1:10 PM Steve Dower <steve.dower at python.org> wrote:

> Not trying to dispute the result (I?d have posted earlier if I was really
> concerned), but it sounds like you?ve signed up to mentor someone for three
> months. Under normal circumstances, the commit bit comes at the end of
> mentorship, not at the start.
>
>
>
> Should we promote other mentees as well? I know there are a few who have
> been deliberately pursuing this recognition (as they attended the language
> summit and/or were specifically requested to attend the core sprint by
> their mentors).
>
>
>
> Top-posted from my Windows 10 phone
>
>
>
> *From: *Victor Stinner <vstinner at redhat.com>
> *Sent: *Tuesday, June 19, 2018 10:44
> *To: *python-committers <python-committers at python.org>
> *Subject: *[python-committers] Results of Pablo's promotion votes: Pablo
> ispromoted as a core dev!
>
>
>
> Hi,
>
>
>
> The result of the vote to to promote Pablo Salingo Salgado as core
> developer
>
> after one week is positive: I declare that Pablo is now a core developer,
>
> congrats! I will follow the usual process to actually make him a core dev,
>
> and ask him to write a short introduction email to this list.
>
>
>
> But I also noted that Pablo lacks experience to be fully autonomous on
> merging
>
> pull requests, so I also requires that Pablo will have to be strictly
> mentored
>
> by me for 3 months. By strict, I mean that Pablo will have to ask me to
>
> merge any pull request. This strict mentoring may be extended depending on
>
> Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to
>
> blame me directly if anything goes wrong :-)
>
>
>
> Giving more responsibilities to Pablo is part of the learning process.
>
> Reviewing as a core developer is different than a review as a contributor:
> core
>
> developers are expected to actually merge a pull request once they approve
> the
>
> change. Merging a pull request is a big responsibility and an investment in
>
> the long-term, because the committer is expected to fix regressions and
> issues
>
> related to this change for next months, if not next years.
>
>
>
> Note: Cheryl Sabella has also been identified as an active contributor who
> may
>
> be promoted as well. I am already discussing with her about that for 1
> month,
>
> but last month, Cheryl chose to wait. I will keep you in touch ;-)
>
>
>
> Vote results.
>
>
>
> Promote (+1): 8 votes
>
>
>
> * Victor Stinner
>
> * Terry Reedy
>
> * Carol Willing
>
> * Gregory P. Smith ("+0.5")
>
> * Eric Snow
>
> * Brett Cannon
>
> * Nathaniel Smith
>
> * Antoine Pitrou ("+0.5")
>
>
>
> Wait (-1): 1 vote
>
>
>
> * Berker Peksa?
>
>
>
> Neutral (0): 1 vote
>
>
>
> * Serhiy Storchaka ("-0")
>
>
>
> Victor
>
> _______________________________________________
>
> python-committers mailing list
>
> python-committers at python.org
>
> https://mail.python.org/mailman/listinfo/python-committers
>
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/2ccd828d/attachment-0001.html>

From ethan at stoneleaf.us  Tue Jun 19 16:26:38 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 19 Jun 2018 13:26:38 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <d911cb0c-ef29-0af1-0bc7-1e82867f4261@egenix.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CAP1=2W5On4PM-YTaEpXkU6Nd-tf_vLCpmpnpq5qy-daq_v1gAg@mail.gmail.com>
 <d911cb0c-ef29-0af1-0bc7-1e82867f4261@egenix.com>
Message-ID: <5B2966FE.4030801@stoneleaf.us>

On 06/19/2018 11:14 AM, M.-A. Lemburg wrote:

> Ok, let me be even clearer :-)
>
> While I understand that there is a need to show the world that
> we need more active core devs, this drive to shelve existing
> developers is not a good way to achieve this.
>
> Here's a simple approach which is effective without all the
> implied social costs of removing core dev flags:
>
> * create a page with the core devs who have at least 10 commits
>    in the last 6 months (the "active" ones):
>
> https://github.com/python/cpython/graphs/contributors?from=2017-12-19&to=2018-06-19&type=c
>
>    (at the moment, this gives 21 entries)

[...]

> * add more ways to add recognition to the core dev title
>    to make it more attractive, e.g. an free tickets to PyCon US
>    for life, your own page on python.org, etc.

I would love tickets to PyCon US.  I've only been able to afford to attend once, and then only because it was being held 
25 miles away.

--
~Ethan~


From antoine at python.org  Tue Jun 19 16:24:22 2018
From: antoine at python.org (Antoine Pitrou)
Date: Tue, 19 Jun 2018 22:24:22 +0200
Subject: [python-committers] Changing commiter status
In-Reply-To: <5B2966FE.4030801@stoneleaf.us>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CAP1=2W5On4PM-YTaEpXkU6Nd-tf_vLCpmpnpq5qy-daq_v1gAg@mail.gmail.com>
 <d911cb0c-ef29-0af1-0bc7-1e82867f4261@egenix.com>
 <5B2966FE.4030801@stoneleaf.us>
Message-ID: <c62c5405-f1b4-cb5c-f1ff-9ab4ae807c7a@python.org>


Le 19/06/2018 ? 22:26, Ethan Furman a ?crit?:
> On 06/19/2018 11:14 AM, M.-A. Lemburg wrote:
> 
>> Ok, let me be even clearer :-)
>>
>> While I understand that there is a need to show the world that
>> we need more active core devs, this drive to shelve existing
>> developers is not a good way to achieve this.
>>
>> Here's a simple approach which is effective without all the
>> implied social costs of removing core dev flags:
>>
>> * create a page with the core devs who have at least 10 commits
>>    in the last 6 months (the "active" ones):
>>
>> https://github.com/python/cpython/graphs/contributors?from=2017-12-19&to=2018-06-19&type=c
>>
>>    (at the moment, this gives 21 entries)
> 
> [...]
> 
>> * add more ways to add recognition to the core dev title
>>    to make it more attractive, e.g. an free tickets to PyCon US
>>    for life, your own page on python.org, etc.
> 
> I would love tickets to PyCon US.  I've only been able to afford to attend once, and then only because it was being held 
> 25 miles away.

Or to whatever-Pycon-suits-you?  I'd probably rather go to EuroPython
than PyCon US.

Regards

Antoine.

From vstinner at redhat.com  Tue Jun 19 17:21:20 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 19 Jun 2018 23:21:20 +0200
Subject: [python-committers] Results of Pablo's promotion votes: Pablo
 is promoted as a core dev!
Message-ID: <CA+3bQGE9Qm7TKVRyLLZAPfzBfSGEGm+C8tSHEqtCVDv-j8=0hQ@mail.gmail.com>

>  it sounds like you?ve signed up to mentor someone for three months.
Under normal circumstances, the commit bit comes at the end of mentorship,
not at the start.

I am already mentoring him since January, it's not a start.

I recall that I was scared of doing anything when I became a core dev. And
I was right to be scared because I quickly broke the whole fleet of
buildbots :-) As I new core, I would have been happy to have someone to
guide me at the beginning :-)

> Should we promote other mentees as well? I know there are a few who have
been deliberately pursuing this recognition (as they attended the language
summit and/or were specifically requested to attend the core sprint by
their mentors).

Yes please! The end of a dev cycle (3.7) is a good opportunity for that.

Victor


>
>
>
> Top-posted from my Windows 10 phone
>
>
>
> From: Victor Stinner
> Sent: Tuesday, June 19, 2018 10:44
> To: python-committers
> Subject: [python-committers] Results of Pablo's promotion votes: Pablo
ispromoted as a core dev!
>
>
>
> Hi,
>
>
>
> The result of the vote to to promote Pablo Salingo Salgado as core
developer
>
> after one week is positive: I declare that Pablo is now a core developer,
>
> congrats! I will follow the usual process to actually make him a core dev,
>
> and ask him to write a short introduction email to this list.
>
>
>
> But I also noted that Pablo lacks experience to be fully autonomous on
merging
>
> pull requests, so I also requires that Pablo will have to be strictly
mentored
>
> by me for 3 months. By strict, I mean that Pablo will have to ask me to
>
> merge any pull request. This strict mentoring may be extended depending on
>
> Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to
>
> blame me directly if anything goes wrong :-)
>
>
>
> Giving more responsibilities to Pablo is part of the learning process.
>
> Reviewing as a core developer is different than a review as a
contributor: core
>
> developers are expected to actually merge a pull request once they
approve the
>
> change. Merging a pull request is a big responsibility and an investment
in
>
> the long-term, because the committer is expected to fix regressions and
issues
>
> related to this change for next months, if not next years.
>
>
>
> Note: Cheryl Sabella has also been identified as an active contributor
who may
>
> be promoted as well. I am already discussing with her about that for 1
month,
>
> but last month, Cheryl chose to wait. I will keep you in touch ;-)
>
>
>
> Vote results.
>
>
>
> Promote (+1): 8 votes
>
>
>
> * Victor Stinner
>
> * Terry Reedy
>
> * Carol Willing
>
> * Gregory P. Smith ("+0.5")
>
> * Eric Snow
>
> * Brett Cannon
>
> * Nathaniel Smith
>
> * Antoine Pitrou ("+0.5")
>
>
>
> Wait (-1): 1 vote
>
>
>
> * Berker Peksa?
>
>
>
> Neutral (0): 1 vote
>
>
>
> * Serhiy Storchaka ("-0")
>
>
>
> Victor
>
> _______________________________________________
>
> python-committers mailing list
>
> python-committers at python.org
>
> https://mail.python.org/mailman/listinfo/python-committers
>
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/0ec42535/attachment.html>

From brett at python.org  Tue Jun 19 18:43:18 2018
From: brett at python.org (Brett Cannon)
Date: Tue, 19 Jun 2018 15:43:18 -0700
Subject: [python-committers] Changing commiter status
In-Reply-To: <CAP7+vJJ8Ebz6bLvimzjoUEA6fsw3wALnRzR3fGngwvxB9R4oOQ@mail.gmail.com>
References: <CA+3bQGEde+p5u2QG-LvBU8L901yxXe6EPpjwYKXih_q-r9Nr9w@mail.gmail.com>
 <f4a651b3-e344-6824-b90a-c15ade6eaf19@egenix.com>
 <CADiSq7cWYo7oU6z=LdDggyceyjw=RdrahjF35LfrEK5bnOn6WA@mail.gmail.com>
 <CAP1=2W65HBGQUFyjTLTTmEWjmgHOVc-f33cyeThk_pcRc1P9tA@mail.gmail.com>
 <CAP7+vJJimwtNi4kDnhcL2skkFPo4VLTXW1RePp8Y-QXe3vBo6w@mail.gmail.com>
 <a417d1e1-a3f0-1915-478c-5e407ac4fd73@egenix.com>
 <CACac1F_+x_mfG-MSb_x75M4vCnxNAm_0G5TH-pDYcCjgt4ANew@mail.gmail.com>
 <CAOTb1wcM2Gc4b43OTsQAoofp-xth9_D4hEVmHFatUtS+mtfgTw@mail.gmail.com>
 <CAP7+vJLK76kaBj+=ZAf0h4ALxJOF=apXroqLzktQoW7pyFh3rA@mail.gmail.com>
 <CAP1=2W5nmB=O6op-AkTLpQbe5gFy7rnWdaLn-7V21=+=86zMvg@mail.gmail.com>
 <5B295FA7.8040201@stoneleaf.us>
 <CAP7+vJJ8Ebz6bLvimzjoUEA6fsw3wALnRzR3fGngwvxB9R4oOQ@mail.gmail.com>
Message-ID: <CAP1=2W40gZAww8tnFWoxRh6j86k40LHFYspiOa65w4MxSgCt0w@mail.gmail.com>

On Tue, 19 Jun 2018 at 13:16 Guido van Rossum <guido at python.org> wrote:

> I'm happy to see you do this. It'll be very interesting what kind of
> responses you get. Do you know how to get the list of 130 people? (I don't,
> but Mariatta probably has it already.)
>

WFM! Thanks, Ethan!

I guess the first step is to go through
https://bugs.python.org/user?iscommitter=1&@action=search&@sort=github&@pagesize=300
and contact the folks missing a GitHub username and to track who says "yes"
or "no" in https://devguide.python.org/developers/ in new active/emeritus
lists (opened https://github.com/python/devguide/issues/390 to track the
list change). After that would be to go through the Python Core team on
GitHub -- which should match who has a GitHub username on b.p.o -- and then
correlate that with who has committed in the last year on appropriate repos
and then reach out to those people.

-Brett


> On Tue, Jun 19, 2018 at 12:51 PM Ethan Furman <ethan at stoneleaf.us> wrote:
>
>> On 06/19/2018 11:17 AM, Brett Cannon wrote:
>> > On Mon, 18 Jun 2018 at 17:56 Guido van Rossum wrote:
>>
>> >> I'd do it as follows. This basically makes withdrawal voluntary unless
>>  >> they don't respond at all.
>> >>
>> >> 1. Make a list of people who've not shown any sign of activity (on the
>>  >> b.p.o. or GitHub, as reviewer or committer) for at least one year.
>>  >>
>> >> 2. Email all of them, asking if they still want to be a core dev.
>> Choices
>>  >> could include
>> >> ?  a. Yes
>> >> ?  b. Keep the logo and b.p.o. access but disable GitHub key
>> >> ?  c. Drop everything
>>  >>
>> >> 3. If someone doesn't respond despite repeated attempts (maybe using
>>  >> different email addresses or social media) then after 4 weeks assume
>>  >> they meant to answer (c). But if they write back later they can be
>>  >> restored according to their preference (a, b, c), no questions asked.
>> >
>> > One point I want to make about this pull approach versus a push one is
>> this
>>  > is going to be a lot of work. :) For the "no GitHub username"
>> situation on
>>  > bugs.python.org <http://bugs.python.org> there are 80 people to reach
>> out
>>  > to. For people with commit rights who have not committed in the past
>> year
>>  > to CPython (because that's the best data point I have without writing
>> custom
>>  > code to find out who has commented on a PR recently), that would
>> require
>>  > reaching out to an additional 50 people. So we're looking at
>> potentially up
>>  > to 130 people to try and track down.
>>
>> I'm happy to do this.
>>
>> > We can make a complete list as people seem to want that and have it be
>> active
>>  > versus emeritus and list the year people got their commit rights.
>>
>> > At the end of that month whomever is still listed as emeritus we turn
>> off
>>  > their commit access and b.p.o extras. We announce this here,
>> python-dev,
>> > social media, etc. IOW this becomes more opt-in/push than opt-out/pull.
>>
>> The problem with this approach as it's one time -- as soon as someone
>> fades away it's once again out of date.
>>
>> I'll take on the task of contacting the 130 people to get this started,
>> then once a year somebody does the same thing
>> with whichever handful of people have gone dormant that year.
>>
>> Sound fair?
>>
>> --
>> ~Ethan~
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180619/c4c7ec3c/attachment-0001.html>

From vstinner at redhat.com  Wed Jun 20 05:20:44 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 20 Jun 2018 11:20:44 +0200
Subject: [python-committers] Results of Pablo's promotion votes: Pablo
 is promoted as a core dev!
In-Reply-To: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
References: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
Message-ID: <CA+3bQGE8OFwudBChN=_WjUfEB7h7PhibFMmDcdvc1cs3qMsufQ@mail.gmail.com>

2018-06-19 19:43 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> The result of the vote to to promote Pablo Salingo Salgado as core developer
> after one week is positive: I declare that Pablo is now a core developer,
> congrats! I will follow the usual process to actually make him a core dev,
> and ask him to write a short introduction email to this list.

Oh, I'm sorry, I made two typos in Pablo's full name :-( His name is:
Pablo *Galindo* Salgado.

Victor

From pablogsal at gmail.com  Wed Jun 20 11:30:09 2018
From: pablogsal at gmail.com (Pablo Galindo Salgado)
Date: Wed, 20 Jun 2018 16:30:09 +0100
Subject: [python-committers] Introduction - Pablo Galindo Salgado
Message-ID: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>

Hi everyone,

I would like to thank everyone for giving me their trust and allow me to be
part of the team. Is really an honor
to be part of such an outstanding family! I will put work and commitment in
all areas of CPython maintenance
and development and I will help as much as I can other core devs,
contributors and everyone in the community.
I will do so with extra care so nobody will be disappointed for this
decision. I will fight as well to help making the
Python community as inclusive and diverse as possible for everyone. Also, I
will happily continue to work with Victor
making sure the buildbots are happy and green.

As a final note, I would like to thank Victor for his trust, encouragement
and kindness, for all the time mentoring
me and for vouching for me in this process.

Thank you everyone for you support and for your work improving Python and
the Python community!

Regards from cloudy London,
Pablo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180620/735ae378/attachment.html>

From zachary.ware+pydev at gmail.com  Wed Jun 20 11:47:06 2018
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Wed, 20 Jun 2018 10:47:06 -0500
Subject: [python-committers] Introduction - Pablo Galindo Salgado
In-Reply-To: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
References: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
Message-ID: <CAKJDb-Oyu1SDwApQ+OOAKGOYjNuEgCsn23ZNuORHG-UEOMJ8YA@mail.gmail.com>

On Wed, Jun 20, 2018 at 10:30 AM, Pablo Galindo Salgado
<pablogsal at gmail.com> wrote:
> Hi everyone,

Hi Pablo, welcome, and congratulations!

> I will do so with extra care so nobody will be disappointed for this
> decision.

Because you're human, you're going to screw something up at some
point, just as each of us has done already and will do again :).
Don't worry about it too much; just try to exercise good judgement,
accept (hopefully constructive) criticism, try to fix things when you
do break them and ask for help when you can't do it yourself.  And
remember to have fun.  After all, we're all volunteers; why are we
doing this if we're not enjoying it?

-- 
Zach

From ethan at stoneleaf.us  Wed Jun 20 12:00:29 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 20 Jun 2018 09:00:29 -0700
Subject: [python-committers] Introduction - Pablo Galindo Salgado
In-Reply-To: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
References: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
Message-ID: <5B2A7A1D.1060209@stoneleaf.us>

Welcome!!  I remember how excited I was to be offered a core-dev position.  It really is a cool thing.

On 06/20/2018 08:30 AM, Pablo Galindo Salgado wrote:

> Thank you everyone for you support and for your work improving Python and the Python community!

Thank you for be willing to join in that work.  And don't worry -- the terror of screwing up the second time is nothing 
like the terror of screwing up the first!  :-)

--
~Ethan~

From guido at python.org  Wed Jun 20 12:27:42 2018
From: guido at python.org (Guido van Rossum)
Date: Wed, 20 Jun 2018 09:27:42 -0700
Subject: [python-committers] Introduction - Pablo Galindo Salgado
In-Reply-To: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
References: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
Message-ID: <CAP7+vJ+tkXuFnddbL8ek30ekMUSEX7fcYNSgofhN2Hd30L_PPw@mail.gmail.com>

Welcome Pablo! I am sure you will do great and I am looking forward to
hearing from you more.

On Wed, Jun 20, 2018 at 8:30 AM Pablo Galindo Salgado <pablogsal at gmail.com>
wrote:

> Hi everyone,
>
> I would like to thank everyone for giving me their trust and allow me to
> be part of the team. Is really an honor
> to be part of such an outstanding family! I will put work and commitment
> in all areas of CPython maintenance
> and development and I will help as much as I can other core devs,
> contributors and everyone in the community.
> I will do so with extra care so nobody will be disappointed for this
> decision. I will fight as well to help making the
> Python community as inclusive and diverse as possible for everyone. Also, I
> will happily continue to work with Victor
> making sure the buildbots are happy and green.
>
> As a final note, I would like to thank Victor for his trust, encouragement
> and kindness, for all the time mentoring
> me and for vouching for me in this process.
>
> Thank you everyone for you support and for your work improving Python and
> the Python community!
>
> Regards from cloudy London,
> Pablo
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180620/53b62fd6/attachment.html>

From senthil at uthcode.com  Thu Jun 21 19:01:41 2018
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 21 Jun 2018 16:01:41 -0700
Subject: [python-committers] Introduction - Pablo Galindo Salgado
In-Reply-To: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
References: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
Message-ID: <CAPOVWORYd87iC8FfCbEnNs3CLvNnuwHoEAM6oV_SmOn9JC5x0Q@mail.gmail.com>

Welcome, Pablo!

Thank you, Victor, for enabling new developers!

Cheers,
Senthil


On Wed, Jun 20, 2018 at 8:30 AM, Pablo Galindo Salgado <pablogsal at gmail.com>
wrote:

> Hi everyone,
>
> I would like to thank everyone for giving me their trust and allow me to
> be part of the team. Is really an honor
> to be part of such an outstanding family! I will put work and commitment
> in all areas of CPython maintenance
> and development and I will help as much as I can other core devs,
> contributors and everyone in the community.
> I will do so with extra care so nobody will be disappointed for this
> decision. I will fight as well to help making the
> Python community as inclusive and diverse as possible for everyone. Also, I
> will happily continue to work with Victor
> making sure the buildbots are happy and green.
>
> As a final note, I would like to thank Victor for his trust, encouragement
> and kindness, for all the time mentoring
> me and for vouching for me in this process.
>
> Thank you everyone for you support and for your work improving Python and
> the Python community!
>
> Regards from cloudy London,
> Pablo
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180621/898bfa7f/attachment.html>

From senthil at uthcode.com  Thu Jun 21 19:03:27 2018
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 21 Jun 2018 16:03:27 -0700
Subject: [python-committers] Results of Pablo's promotion votes: Pablo
 is promoted as a core dev!
In-Reply-To: <CA+3bQGE8OFwudBChN=_WjUfEB7h7PhibFMmDcdvc1cs3qMsufQ@mail.gmail.com>
References: <CA+3bQGHyYTzZQVOUpXGQgR71Gr=LTVeRk0hxUoGRk5SFnUn0gw@mail.gmail.com>
 <CA+3bQGE8OFwudBChN=_WjUfEB7h7PhibFMmDcdvc1cs3qMsufQ@mail.gmail.com>
Message-ID: <CAPOVWORSYZ_13VYrns7w4ThZ00BBodrdi2=P9qgPxEMqQj64kg@mail.gmail.com>

On Wed, Jun 20, 2018 at 2:20 AM, Victor Stinner <vstinner at redhat.com>
wrote:
>
> > The result of the vote to to promote Pablo Salingo Salgado as core
> developer
> > after one week is positive: I declare that Pablo is now a core developer.



I couldn't participate this in vote. I just want to thank you introducing a
new developer.

Thank you,
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180621/0a0495ed/attachment.html>

From ncoghlan at gmail.com  Fri Jun 22 08:25:08 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 22 Jun 2018 22:25:08 +1000
Subject: [python-committers] Introduction - Pablo Galindo Salgado
In-Reply-To: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
References: <CAFjbc8GTZG_keBUC0c285N3FJ82kO3EeTQJvdvkh+x5K_odcjw@mail.gmail.com>
Message-ID: <CADiSq7deCi3Jofz9XS8=K9Nq1GsLam1x7_FPs_ec3xoGcMxq6w@mail.gmail.com>

On 21 June 2018 at 01:30, Pablo Galindo Salgado <pablogsal at gmail.com> wrote:
> Hi everyone,
>
> I would like to thank everyone for giving me their trust and allow me to be
> part of the team. Is really an honor
> to be part of such an outstanding family!

Welcome! And as Zachary said, while it's definitely good to be
careful, we also have lots of systems in place to help us correct
course when we inevitably do make mistakes :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From eric at trueblade.com  Sat Jun 23 08:37:09 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 23 Jun 2018 08:37:09 -0400
Subject: [python-committers] If I backport to 3.7, it will not go into 3.7.0,
 correct?
Message-ID: <3c8d957c-c52e-4db5-3cef-d858a564b46c@trueblade.com>

I have a few things I want to fix in 3.7.1, but don't need to be 3.7.0. 
I can backport those to the 3.7 branch now, correct?

Reading Ned's message I wasn't exactly sure of the timing and don't want 
to screw things up. I assume he's keeping a private branch for 3.7.0.

Eric

From tjreedy at udel.edu  Sat Jun 23 10:31:35 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 23 Jun 2018 10:31:35 -0400
Subject: [python-committers] If I backport to 3.7,
 it will not go into 3.7.0, correct?
In-Reply-To: <3c8d957c-c52e-4db5-3cef-d858a564b46c@trueblade.com>
References: <3c8d957c-c52e-4db5-3cef-d858a564b46c@trueblade.com>
Message-ID: <26768c23-a3c0-535a-da14-f1abbfb2c405@udel.edu>

On 6/23/2018 8:37 AM, Eric V. Smith wrote:
> I have a few things I want to fix in 3.7.1, but don't need to be 3.7.0. 
> I can backport those to the 3.7 branch now, correct?

Correct. 'backport 3.7' == backport into 3.7.1.  I have done this 
several times already.

> Reading Ned's message I wasn't exactly sure of the timing and don't want 
> to screw things up. I assume he's keeping a private branch for 3.7.0.

We no longer embargo an x.y branch during the release process, which is 
much nicer.  If you wanted something in 3.7.0 you would have to mark as 
release blocker and be very persuasive that he should cherry-pick into 
the 3.7.0 release branch.

From eric at trueblade.com  Sat Jun 23 10:37:53 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Sat, 23 Jun 2018 10:37:53 -0400
Subject: [python-committers] If I backport to 3.7,
 it will not go into 3.7.0, correct?
In-Reply-To: <26768c23-a3c0-535a-da14-f1abbfb2c405@udel.edu>
References: <3c8d957c-c52e-4db5-3cef-d858a564b46c@trueblade.com>
 <26768c23-a3c0-535a-da14-f1abbfb2c405@udel.edu>
Message-ID: <59CAC430-EBDE-44E9-998F-D07B81F3CAF2@trueblade.com>

Thanks, Terry. 

--
Eric

> On Jun 23, 2018, at 10:31 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> 
>> On 6/23/2018 8:37 AM, Eric V. Smith wrote:
>> I have a few things I want to fix in 3.7.1, but don't need to be 3.7.0. I can backport those to the 3.7 branch now, correct?
> 
> Correct. 'backport 3.7' == backport into 3.7.1.  I have done this several times already.
> 
>> Reading Ned's message I wasn't exactly sure of the timing and don't want to screw things up. I assume he's keeping a private branch for 3.7.0.
> 
> We no longer embargo an x.y branch during the release process, which is much nicer.  If you wanted something in 3.7.0 you would have to mark as release blocker and be very persuasive that he should cherry-pick into the 3.7.0 release branch.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


From nad at python.org  Sat Jun 23 14:04:05 2018
From: nad at python.org (Ned Deily)
Date: Sat, 23 Jun 2018 14:04:05 -0400
Subject: [python-committers] If I backport to 3.7,
 it will not go into 3.7.0, correct?
In-Reply-To: <26768c23-a3c0-535a-da14-f1abbfb2c405@udel.edu>
References: <3c8d957c-c52e-4db5-3cef-d858a564b46c@trueblade.com>
 <26768c23-a3c0-535a-da14-f1abbfb2c405@udel.edu>
Message-ID: <65055380-5DD1-43CB-8254-DD932179AE4E@python.org>

On Jun 23, 2018, at 10:31, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> On 6/23/2018 8:37 AM, Eric V. Smith wrote:
>> I have a few things I want to fix in 3.7.1, but don't need to be 3.7.0. I can backport those to the 3.7 branch now, correct?
> 
> Correct. 'backport 3.7' == backport into 3.7.1.  I have done this several times already.
> 
>> Reading Ned's message I wasn't exactly sure of the timing and don't want to screw things up. I assume he's keeping a private branch for 3.7.0.
> 
> We no longer embargo an x.y branch during the release process, which is much nicer.  If you wanted something in 3.7.0 you would have to mark as release blocker and be very persuasive that he should cherry-pick into the 3.7.0 release branch.

Thanks, Terry, that description is exactly right.

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Tue Jun 26 02:39:35 2018
From: nad at python.org (Ned Deily)
Date: Tue, 26 Jun 2018 02:39:35 -0400
Subject: [python-committers] 3.7.0 / 3.6.6 Update: all systems go for final
 releases!
Message-ID: <2EFA992F-1AF8-43D7-A350-8E9FEB6A3002@python.org>

A quick update: after many months we are at the finish line. We are on
track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on
2018-06-27. Since 3.7.0rc1 shipped 2 weeks ago, I am aware of only two
noteworthy regressions that have been identified and now fixed. Since
the issues for both have the potential to impact some (but small)
subsets of 3.7.0 users and the fixes for both are straightforward and
appear to be low-risk, I am planning to cherry-pick the fixes for them
into 3.7.0 final without either another release candidate cycle or
waiting for 3.7.1. There may be some doc fixes that get cherry-picked
as well. At the moment, there are no plans for any bug cherry-picks for
3.6.6 final.

As you know, a new feature release is a big deal and something for all
of us to be proud of.  A new feature release also has various, mostly
minor, impacts to lots of different parts of our development
infrastructure: to multiple branches of the cpython repo, to
documentation builds, to different parts of the python.org web site,
etc. You will start to see some of the changes roll out over the next 24
to 36 hours and it may take some time until everything is in place.
So please be patient until the official release announcement goes out
before reporting release-related issues. Also be advised that over the
same period, there may be a few brief periods where commit access to
various cpython branches is blocked in order to do the necessary
release engineering. If you run into this, for example when trying to
merge a PR, please try again in a few hours.

Thanks and more later!

https://bugs.python.org/issue33851
https://bugs.python.org/issue33932

--
  Ned Deily
  nad at python.org -- []


From eric at trueblade.com  Tue Jun 26 03:31:52 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 26 Jun 2018 03:31:52 -0400
Subject: [python-committers] 3.7.0 / 3.6.6 Update: all systems go for
 final releases!
In-Reply-To: <2EFA992F-1AF8-43D7-A350-8E9FEB6A3002@python.org>
References: <2EFA992F-1AF8-43D7-A350-8E9FEB6A3002@python.org>
Message-ID: <5BA88066-C9F6-4ECF-86CC-4E6F1A4FD483@trueblade.com>

Congrats, Ned. Thank you for all of your hard work!

--
Eric

> On Jun 26, 2018, at 2:39 AM, Ned Deily <nad at python.org> wrote:
> 
> A quick update: after many months we are at the finish line. We are on
> track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on
> 2018-06-27. Since 3.7.0rc1 shipped 2 weeks ago, I am aware of only two
> noteworthy regressions that have been identified and now fixed. Since
> the issues for both have the potential to impact some (but small)
> subsets of 3.7.0 users and the fixes for both are straightforward and
> appear to be low-risk, I am planning to cherry-pick the fixes for them
> into 3.7.0 final without either another release candidate cycle or
> waiting for 3.7.1. There may be some doc fixes that get cherry-picked
> as well. At the moment, there are no plans for any bug cherry-picks for
> 3.6.6 final.
> 
> As you know, a new feature release is a big deal and something for all
> of us to be proud of.  A new feature release also has various, mostly
> minor, impacts to lots of different parts of our development
> infrastructure: to multiple branches of the cpython repo, to
> documentation builds, to different parts of the python.org web site,
> etc. You will start to see some of the changes roll out over the next 24
> to 36 hours and it may take some time until everything is in place.
> So please be patient until the official release announcement goes out
> before reporting release-related issues. Also be advised that over the
> same period, there may be a few brief periods where commit access to
> various cpython branches is blocked in order to do the necessary
> release engineering. If you run into this, for example when trying to
> merge a PR, please try again in a few hours.
> 
> Thanks and more later!
> 
> https://bugs.python.org/issue33851
> https://bugs.python.org/issue33932
> 
> --
>  Ned Deily
>  nad at python.org -- []
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From vstinner at redhat.com  Thu Jun 28 07:04:11 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 28 Jun 2018 13:04:11 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>

It seems like the PEP 572 discussions restarted on python-dev mailing
list with more than 100 emails in one week.

Stupid idea: we created a mailing list just to fix os.random(): PEP
522 and PEP 524, whereas these discussions were not the ones with the
most emails. Why not creating a new pep572 mailing list for the ones
who don't want to follow PEP 572 discussions?

A dedicated mailing list may help to discuss subtopics by opening new threads.

*Maybe* discussions would be more constructive on a dedicated mailing
list with less traffic and narrower audience?

Victor

2018-05-19 0:25 GMT+02:00 Guido van Rossum <guido at python.org>:
> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)
>
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.
>
> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.
>
> PEP authors may also choose to use a different repo hosting site, e.g.
> Bitbucket or GitLab. We can provide a script that allows checking the
> formatting of the PEP easily (basically pep2html.py from the peps repo).
>
> Using a separate repo per PEP has the advantage that people interested in a
> topic can subscribe to all traffic in that repo -- if we were to use the
> tracker of the peps repo you would have to subscribe to all peps traffic.
>
> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From antoine at python.org  Thu Jun 28 07:33:55 2018
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 28 Jun 2018 13:33:55 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGG+Lb5GHyuagDV3eh5gB3RZ2RpGzP0P7qgBek-C6ZaoZw@mail.gmail.com>
Message-ID: <14a25df5-d869-b4a4-ccce-cf4c5bf768dc@python.org>


Le 28/06/2018 ? 13:04, Victor Stinner a ?crit?:
> It seems like the PEP 572 discussions restarted on python-dev mailing
> list with more than 100 emails in one week.
> 
> Stupid idea: we created a mailing list just to fix os.random(): PEP
> 522 and PEP 524, whereas these discussions were not the ones with the
> most emails. Why not creating a new pep572 mailing list for the ones
> who don't want to follow PEP 572 discussions?

PEP 572 is a language-wide change.  Presumably those who don't want to
follow discussions will still want to give their opinion (or informal
vote) at the end.  Which will give rise to other discussions...

What strikes me is that we have such long-lasting and intense discussion
about a feature which, whether approved or not, will not significantly
change Python's popularity or appeal or ability to solve real-world
problems.

Perhaps this is a case where ? Nature abhors a vacuum ? : we're getting
focussed on whatever comes up to fill the narrative of Python's evolution.

Regards

Antoine.

From nad at python.org  Wed Jun 27 20:58:03 2018
From: nad at python.org (Ned Deily)
Date: Wed, 27 Jun 2018 20:58:03 -0400
Subject: [python-committers] Python 3.7.0 is now available! (and so is 3.6.6)
Message-ID: <6FF553CD-6580-4939-A5E4-78143633BF1F@python.org>

On behalf of the Python development community and the Python 3.7 release
team, we are pleased to announce the availability of Python 3.7.0.
Python 3.7.0 is the newest feature release of the Python language, and
it contains many new features and optimizations. You can find Python
3.7.0 here:

    https://www.python.org/downloads/release/python-370/

Most third-party distributors of Python should be making 3.7.0 packages
available soon.

See the "What?s New In Python 3.7" document
(https://docs.python.org/3.7/whatsnew/3.7.html) for more information
about features included in the 3.7 series. Detailed information about
the changes made in 3.7.0 can be found in its change log. Maintenance
releases for the 3.7 series will follow at regular intervals starting in
July of 2018.

We hope you enjoy Python 3.7!

P.S. We are also happy to announce the availability of Python 3.6.6, the
next maintenance release of Python 3.6:

    https://www.python.org/downloads/release/python-366/

Thanks to all of the many volunteers who help make Python Development
and these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the
Python Software Foundation.

    https://www.python.org/psf/

--
  Ned Deily
  nad at python.org -- []