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: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> Message-ID: 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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> 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: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <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 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: 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: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> Message-ID: On 1 June 2018 at 20:29, Barry Warsaw wrote: > On Jun 1, 2018, at 16:54, Antoine Pitrou 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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> Message-ID: 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 wrote: On Jun 1, 2018, at 16:54, Antoine Pitrou 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: 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: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> Message-ID: > > "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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> Message-ID: On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya 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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> 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 > wrote: > > > > On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya > 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. > _______________________________________________ > 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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> Message-ID: Hi, On Sat, Jun 2, 2018 at 10:26 PM, Brett Cannon wrote: > > > On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya > 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: > > 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 > > 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: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <96b1f3ce-c1ef-094f-91a9-645e6a0bc430@udel.edu> Message-ID: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> 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: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: 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 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: 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 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 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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> Message-ID: On Sat, 2 Jun 2018 at 14:58 Ezio Melotti wrote: > Hi, > > On Sat, Jun 2, 2018 at 10:26 PM, Brett Cannon wrote: > > > > > > On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya > > 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: > > > > > 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 > > > > > > 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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: On 3 June 2018 at 11:07, Guido van Rossum 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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> Message-ID: On 3 June 2018 at 12:49, Brett Cannon wrote: > > On Sat, 2 Jun 2018 at 14:58 Ezio Melotti 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: 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: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: On Sun, Jun 3, 2018 at 11:27 AM, Antoine Pitrou 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: Le 03/06/2018 ? 12:36, Berker Peksa? a ?crit?: > On Sun, Jun 3, 2018 at 11:27 AM, Antoine Pitrou 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: On Sat, 2 Jun 2018 at 18:08 Guido van Rossum 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 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 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: 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: 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: References: Message-ID: 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 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: 2018-06-03 10:27 GMT+02:00 Antoine Pitrou : > 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: [Victor Stinner ] > ... > 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: 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: References: Message-ID: 2018-06-03 22:23 GMT+02:00 Terry Reedy : > 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: 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> Message-ID: 2018-06-03 3:07 GMT+02:00 Guido van Rossum : > 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: References: Message-ID: 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: References: Message-ID: 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 : > 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: 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: <40zf7g22qHz12yjK@mail.python.org> Message-ID: <19F3FBBC-C938-41C8-A600-87AE21DB2547@python.org> On Jun 3, 2018, at 22:30, Steve Dower 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: 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: 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: References: Message-ID: 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 : > 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: References: Message-ID: 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 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 : > > 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: 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: References: Message-ID: 2018-06-04 18:18 GMT+02:00 Brett Cannon : > 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: References: Message-ID: > > 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: 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: References: 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 : >> 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: <40zf7g22qHz12yjK@mail.python.org> <19F3FBBC-C938-41C8-A600-87AE21DB2547@python.org> Message-ID: On Sun, 3 Jun 2018 at 20:30 Ned Deily wrote: > On Jun 3, 2018, at 22:30, Steve Dower 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: 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: <9f1c62f7-df2c-ed02-e003-cbe504fd5f56@python.org> Message-ID: 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 : > On 04Jun2018 0932, Victor Stinner wrote: >> >> 2018-06-04 18:18 GMT+02:00 Brett Cannon : >>> >>> 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: References: <9f1c62f7-df2c-ed02-e003-cbe504fd5f56@python.org> Message-ID: 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 : > On 04Jun2018 0932, Victor Stinner wrote: >> >> 2018-06-04 18:18 GMT+02:00 Brett Cannon : >>> >>> 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: 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: References: Message-ID: On Sun, 3 Jun 2018 at 13:23 Terry Reedy 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: 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: References: 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 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: <6A094644-0CDF-426A-A3A2-1A2CB5D73FAF@stufft.io> Message-ID: +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 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 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: 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: References: Message-ID: 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 : > 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: References: <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> <5B13376F.3030109@stoneleaf.us> 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: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> <7cd3cfd6-8ad1-c7d3-e210-767a990dfa57@python.org> <030688B3-C84B-4AAB-8EA5-5FE3E348F5EB@python.org> <40ykBg6d1DzFqpT@mail.python.org> Message-ID: On 3 June 2018 at 17:00, Nick Coghlan 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: 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: 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: 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 (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: References: Message-ID: On 6 June 2018 at 08:53, Steve Dower 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: 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: References: Message-ID: 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 (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: 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: <5b17ec05.1c69fb81.5c2e.6710SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: > 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 : > 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 (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: References: 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: References: Message-ID: 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 : > 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 : >> 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: 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: 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: References: Message-ID: <49FF8E25-DC2D-45E1-812D-1533C0E81A24@python.org> On Jun 11, 2018, at 01:38, Tal Einat 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: 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: References: 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: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: 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: 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: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: 2018-06-13 18:43 GMT+02:00 Terry Reedy : >> 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: 2018-06-13 21:38 GMT+02:00 Serhiy Storchaka : >> 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: On Wed, Jun 13, 2018 at 10:38 PM, Serhiy Storchaka 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> 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 > 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: 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: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com> Message-ID: 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com> Message-ID: <8DE66BB4-D4F9-4D43-BA29-BB0FCE83A37F@gmail.com> > On Jun 13, 2018, at 7:30 PM, Terry Reedy 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: 2018-06-14 0:26 GMT+02:00 Berker Peksa? : > 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 31 Victor Stinner 24 Yury Selivanov 18 Andr?s Delfino 16 Ned Deily --- 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 "). 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: On Thu, Jun 14, 2018 at 11:46 AM, Victor Stinner wrote: > 2018-06-14 0:26 GMT+02:00 Berker Peksa? : >> 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: References: Message-ID: 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 : > 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: References: Message-ID: 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 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 : > > 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: 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: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com> Message-ID: On Wed, 13 Jun 2018 at 16:11 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 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 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: 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: References: Message-ID: On Wed, Jun 13, 2018 at 10:16 AM 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. > > [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: References: Message-ID: 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 wrote: > 2018-05-16 11:31 GMT-04:00 Victor Stinner : > > 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: 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksa? 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: References: Message-ID: I just wanted to say I agree with everything Eric said, for +1 from me. On Thu, Jun 14, 2018, 14:34 Eric Snow, wrote: > On Wed, Jun 13, 2018 at 10:16 AM 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. > > > > [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: 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: 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: 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 : > 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> 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: 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: References: <6fac8fb7.66bf.16402839880.Coremail.angwerzx@126.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 : > 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: 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> 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? 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: 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> Message-ID: On Thu, Jun 14, 2018 at 8:06 PM Nathaniel Smith wrote: > On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksa? 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: 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: References: Message-ID: "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: 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 `_. The merge action is restricted to core developers. Maintainers: active core developers (June 2018: around 34 core devs). * `Bug triage `_: closing a bug requires the bug triage permission. Maintainers: active core developers. * `Check for buildbot failures `_: 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 `_ 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 `_. 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: References: Message-ID: 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 : > 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: References: Message-ID: > 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: References: Message-ID: 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: References: Message-ID: 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: References: 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 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, , 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: 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: <6A17A502-028E-422C-8C8C-2AF0AC8F01CE@cwi.nl> Message-ID: 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 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 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, , 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: 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: References: <6A17A502-028E-422C-8C8C-2AF0AC8F01CE@cwi.nl> 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 > 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 > > 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, >, > 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/ > > > > _______________________________________________ > 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: References: Message-ID: 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: References: Message-ID: On 18 June 2018 at 18:07, M.-A. Lemburg 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com> 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: References: Message-ID: 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: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com> <70684ccd-8a3d-50f9-7509-5ad8ddf9d91b@python.org> Message-ID: On Mon, 18 Jun 2018 at 11:17 Antoine Pitrou 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: 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: References: Message-ID: On Fri, 15 Jun 2018 at 17:44 Victor Stinner 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 > `_. The merge action is > restricted to core developers. > Maintainers: active core developers (June 2018: around 34 core devs). > * `Bug triage `_: closing a bug requires the > bug triage > permission. Maintainers: active core developers. > * `Check for buildbot failures > >`_: > 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 `_ 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 `_. 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: 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com> <70684ccd-8a3d-50f9-7509-5ad8ddf9d91b@python.org> Message-ID: 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 > 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: References: 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: References: Message-ID: On Mon, 18 Jun 2018 at 06:43 Nick Coghlan wrote: > On 18 June 2018 at 18:07, M.-A. Lemburg 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: 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: References: Message-ID: 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 wrote: > > > On Mon, 18 Jun 2018 at 06:43 Nick Coghlan wrote: > >> On 18 June 2018 at 18:07, M.-A. Lemburg 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: 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: References: Message-ID: 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 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 > wrote: > > > On Mon, 18 Jun 2018 at 06:43 Nick Coghlan > wrote: > On 18 June 2018 at 18:07, M.-A. Lemburg > 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, , 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: 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: References: Message-ID: I propose "emeritus core dev". It's a word that conveys *extra* status. On Mon, Jun 18, 2018 at 12: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. 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 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 wrote: > >> >> >> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan wrote: >> >>> On 18 June 2018 at 18:07, M.-A. Lemburg 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, , 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: 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: References: Message-ID: 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 wrote: > >> >> >> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan wrote: >> >>> On 18 June 2018 at 18:07, M.-A. Lemburg 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: References: 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: References: <6604776e-a339-6c36-1311-edcd777c0104@udel.edu> <371D2022-4FBB-4579-90B5-6080DDC1607F@gmail.com> <70684ccd-8a3d-50f9-7509-5ad8ddf9d91b@python.org> 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 > 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: References: Message-ID: On 18 June 2018 at 20:41, M.-A. Lemburg 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: References: Message-ID: 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 wrote: > On 18 June 2018 at 20:41, M.-A. Lemburg 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: 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: References: Message-ID: 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 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 wrote: > >> On 18 June 2018 at 20:41, M.-A. Lemburg 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: 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: References: Message-ID: On Tue, Jun 19, 2018 at 3:54 AM, Guido van Rossum 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: References: Message-ID: On Mon, 18 Jun 2018 at 12:41 M.-A. Lemburg 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 wrote: > > > >> > >> > >> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan wrote: > >> > >>> On 18 June 2018 at 18:07, M.-A. Lemburg 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: 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: References: Message-ID: On Mon, Jun 18, 2018 at 10:12 PM Tal Einat wrote: > On Tue, Jun 19, 2018 at 3:54 AM, Guido van Rossum > 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: 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: References: Message-ID: 2018-06-19 2:54 GMT+02:00 Guido van Rossum : > 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: References: Message-ID: <8E52FB33-6014-4E2F-9FF9-837CB3A41730@stufft.io> > On Jun 19, 2018, at 1:35 PM, Victor Stinner 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: 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: 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: References: Message-ID: On 19.06.2018 18:39, Brett Cannon wrote: > On Mon, 18 Jun 2018 at 12:41 M.-A. Lemburg 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: References: Message-ID: 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 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 > 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 wrote: >> >>> On 18 June 2018 at 20:41, M.-A. Lemburg 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: 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: References: Message-ID: 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 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 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 >> 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 wrote: >>> >>>> On 18 June 2018 at 20:41, M.-A. Lemburg 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: 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: References: 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 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: References: Message-ID: 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: 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: <5B295FA7.8040201@stoneleaf.us> Message-ID: 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 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 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: 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: <419JxM2dq8zFr22@mail.python.org> Message-ID: 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 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 > *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/ > > > _______________________________________________ > 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: 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: References: 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: <5B2966FE.4030801@stoneleaf.us> Message-ID: 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: > 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: 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: References: <5B295FA7.8040201@stoneleaf.us> Message-ID: On Tue, 19 Jun 2018 at 13:16 Guido van Rossum 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 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 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: 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: References: Message-ID: 2018-06-19 19:43 GMT+02:00 Victor Stinner : > 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: 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: 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: References: Message-ID: On Wed, Jun 20, 2018 at 10:30 AM, Pablo Galindo Salgado 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: References: 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: References: Message-ID: 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 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: 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: References: Message-ID: Welcome, Pablo! Thank you, Victor, for enabling new developers! Cheers, Senthil On Wed, Jun 20, 2018 at 8:30 AM, Pablo Galindo Salgado 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: 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: References: Message-ID: On Wed, Jun 20, 2018 at 2:20 AM, Victor Stinner 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: 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: References: Message-ID: On 21 June 2018 at 01:30, Pablo Galindo Salgado 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 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 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 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: References: Message-ID: 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 : > 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: References: 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 -- []