From ncoghlan at gmail.com Sun Dec 3 08:29:59 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 3 Dec 2017 23:29:59 +1000 Subject: [python-committers] Mostly offline from December 10th through to January 1st Message-ID: Hi folks, Just a heads up that I'll be mostly offline for the last 3 weeks of December. I don't think there's anything in particular coming up that will need my attention specifically (I'm hoping we can get the DeprecationWarning PEP resolved this week), but it does mean I won't be around to review startup refactoring or subinterpreter related PRs if any further work is done on those. Cheers, Nick. P.S. I'd still like to get PEP 558's "Defined semantics for locals()" included in 3.7, but I'm also OK with it slipping to 3.8 - the quirky behaviour that it addresses has been around for a decade and a half, so I don't think anyone is really going to care all that much whether it gets fixed in 2018 or in 2019. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From nad at python.org Mon Dec 4 14:27:29 2017 From: nad at python.org (Ned Deily) Date: Mon, 4 Dec 2017 14:27:29 -0500 Subject: [python-committers] 3.7.0a3 still open Message-ID: <3E7162BE-F5C0-4DDF-8D1B-25DB0EB13BC2@python.org> Congratulations to the owners of the newly accepted PEPs. The code cutoff for 3.7.0 alpha 3 is scheduled for today (along with 3.6.3rc1). I know at least one of the PEPs has code ready to commit. I will hold off on tagging 3.7.0a3 for another 6 hours or so. If you feel your code is adequately reviewed and ready to go, go for it; likewise for normal bug fixes and doc changes. But keep in the mind that there is still one more alpha preview release coming prior to the beta 1 feature code freeze, so no need to panic. -- Ned Deily nad at python.org -- [] From barry at python.org Tue Dec 5 14:21:30 2017 From: barry at python.org (Barry Warsaw) Date: Tue, 5 Dec 2017 14:21:30 -0500 Subject: [python-committers] python-devs/python project on GitLab Message-ID: Back when we were deciding between GitHub and GitLab, we created this project: https://gitlab.com/python-devs/python Unless anyone objects, we?re going to delete this project. We have no need for this now that CPython development is on GitHub. (No, we?re not getting rid of the group, just the project.) 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 guido at python.org Tue Dec 5 20:00:59 2017 From: guido at python.org (Guido van Rossum) Date: Tue, 5 Dec 2017 17:00:59 -0800 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer Message-ID: I'd like to propose Ivan Levkivskyi as a new core committer. He's (re-)written most of the typing.py module and will do so again for Python 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), is co-author on several more (483, 561) and has been acknowledged in yet others (557, 563). He is responsible for at least 16 commits in master. I have worked with him for a long time on typing.py and on mypy (where he is a core dev) and I can vouch for him completely. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Tue Dec 5 20:07:51 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 6 Dec 2017 02:07:51 +0100 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: Hi Guido, Since the typing module is out of my interest area, I didn't notice Ivan contributions, so it's hard for me to give an opinion. Should I understand that he will mostly contribute to the typing module? If (in the beginning?) we restrict him to the typing module, I will simply rely on your judgment Guido. I know that you are following the topic closely and so are very good to estimate his skills. I'm not talking about technically restricting Ivan to the typing module. It's more that I expect him to request an approval by other core developers if he wants to touch other parts of CPython. In my experience, developers are already doing that naturally, but I would prefer to clarify this point. Victor 2017-12-06 2:00 GMT+01:00 Guido van Rossum : > I'd like to propose Ivan Levkivskyi as a new core committer. He's > (re-)written most of the typing.py module and will do so again for Python > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), > is co-author on several more (483, 561) and has been acknowledged in yet > others (557, 563). > > He is responsible for at least 16 commits in master. > > I have worked with him for a long time on typing.py and on mypy (where he is > a core dev) and I can vouch for him completely. > > -- > --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 eric at trueblade.com Tue Dec 5 20:12:01 2017 From: eric at trueblade.com (Eric V. Smith) Date: Tue, 5 Dec 2017 20:12:01 -0500 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: <746EC616-5F86-454F-8BCC-CEE55EFC810E@trueblade.com> +1, without reservation. He was an immense help to me on PEP 557. -- Eric. > On Dec 5, 2017, at 8:00 PM, Guido van Rossum wrote: > > I'd like to propose Ivan Levkivskyi as a new core committer. He's (re-)written most of the typing.py module and will do so again for Python 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), is co-author on several more (483, 561) and has been acknowledged in yet others (557, 563). > > He is responsible for at least 16 commits in master. > > I have worked with him for a long time on typing.py and on mypy (where he is a core dev) and I can vouch for him completely. > > -- > --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 Dec 5 20:22:59 2017 From: guido at python.org (Guido van Rossum) Date: Tue, 5 Dec 2017 17:22:59 -0800 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: Well he also wrote and implemented PEP 562 (overriding __getattr__ and __dir__ on modules). I'd be happy to tell him to gain other developers' trust before barging into other areas. But isn't that how all core devs work by default? On Tue, Dec 5, 2017 at 5:07 PM, Victor Stinner wrote: > Hi Guido, > > Since the typing module is out of my interest area, I didn't notice > Ivan contributions, so it's hard for me to give an opinion. > > Should I understand that he will mostly contribute to the typing > module? If (in the beginning?) we restrict him to the typing module, I > will simply rely on your judgment Guido. I know that you are following > the topic closely and so are very good to estimate his skills. > > I'm not talking about technically restricting Ivan to the typing > module. It's more that I expect him to request an approval by other > core developers if he wants to touch other parts of CPython. In my > experience, developers are already doing that naturally, but I would > prefer to clarify this point. > > Victor > > 2017-12-06 2:00 GMT+01:00 Guido van Rossum : > > I'd like to propose Ivan Levkivskyi as a new core committer. He's > > (re-)written most of the typing.py module and will do so again for Python > > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, > 562), > > is co-author on several more (483, 561) and has been acknowledged in yet > > others (557, 563). > > > > He is responsible for at least 16 commits in master. > > > > I have worked with him for a long time on typing.py and on mypy (where > he is > > a core dev) and I can vouch for him completely. > > > > -- > > --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 Dec 5 22:14:47 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Tue, 05 Dec 2017 19:14:47 -0800 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: <5A2760A7.70901@stoneleaf.us> On 12/05/2017 05:00 PM, Guido van Rossum wrote: > I'd like to propose Ivan Levkivskyi as a new core committer. I thought he already was one. +1 to bring him in! -- ~Ethan~ From tjreedy at udel.edu Tue Dec 5 22:42:58 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 5 Dec 2017 22:42:58 -0500 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: <3e995578-1e41-88f5-eb58-01ac7ac11e24@udel.edu> On 12/5/2017 8:00 PM, Guido van Rossum wrote: > I'd like to propose Ivan Levkivskyi as a new core committer. He's > (re-)written most of the typing.py module and will do so again for > Python 3.7, he's the sole or primary author on several PEPs (526, 544, > 560, 562), is co-author on several more (483, 561) and has been > acknowledged in yet others (557, 563). > > He is responsible for at least 16 commits in master. > > I have worked with him for a long time on typing.py and on mypy (where > he is a core dev) and I can vouch for him completely. Please bring him on. From ncoghlan at gmail.com Tue Dec 5 22:47:23 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 6 Dec 2017 13:47:23 +1000 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: On 6 December 2017 at 11:00, Guido van Rossum wrote: > I'd like to propose Ivan Levkivskyi as a new core committer. He's > (re-)written most of the typing.py module and will do so again for Python > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), > is co-author on several more (483, 561) and has been acknowledged in yet > others (557, 563). > > He is responsible for at least 16 commits in master. > > I have worked with him for a long time on typing.py and on mypy (where he is > a core dev) and I can vouch for him completely. +1 from me - I found him very receptive to feedback and easy to work with when discuss his proposed changes to the runtime typing machinery. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From andrew.svetlov at gmail.com Wed Dec 6 05:26:19 2017 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Wed, 06 Dec 2017 10:26:19 +0000 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: +1 On Wed, Dec 6, 2017 at 5:47 AM Nick Coghlan wrote: > On 6 December 2017 at 11:00, Guido van Rossum wrote: > > I'd like to propose Ivan Levkivskyi as a new core committer. He's > > (re-)written most of the typing.py module and will do so again for Python > > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, > 562), > > is co-author on several more (483, 561) and has been acknowledged in yet > > others (557, 563). > > > > He is responsible for at least 16 commits in master. > > > > I have worked with him for a long time on typing.py and on mypy (where > he is > > a core dev) and I can vouch for him completely. > > +1 from me - I found him very receptive to feedback and easy to work > with when discuss his proposed changes to the runtime typing > machinery. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > 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/ > -- Thanks, Andrew Svetlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at gmail.com Wed Dec 6 08:11:36 2017 From: willingc at gmail.com (Carol Willing) Date: Wed, 6 Dec 2017 07:11:36 -0600 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: <345103F8-E72D-4763-A7DE-D9B69D4D4357@gmail.com> +1 for nice work on the PEPs > On Dec 6, 2017, at 4:26 AM, Andrew Svetlov wrote: > > +1 > > On Wed, Dec 6, 2017 at 5:47 AM Nick Coghlan > wrote: > On 6 December 2017 at 11:00, Guido van Rossum > wrote: > > I'd like to propose Ivan Levkivskyi as a new core committer. He's > > (re-)written most of the typing.py module and will do so again for Python > > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), > > is co-author on several more (483, 561) and has been acknowledged in yet > > others (557, 563). > > > > He is responsible for at least 16 commits in master. > > > > I have worked with him for a long time on typing.py and on mypy (where he is > > a core dev) and I can vouch for him completely. > > +1 from me - I found him very receptive to feedback and easy to work > with when discuss his proposed changes to the runtime typing > machinery. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > 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/ > -- > Thanks, > Andrew Svetlov > _______________________________________________ > 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 Tue Dec 5 21:29:55 2017 From: nad at python.org (Ned Deily) Date: Tue, 5 Dec 2017 21:29:55 -0500 Subject: [python-committers] [RELEASE] Python 3.6.4rc1 and 3.7.0a3 now available for testing Message-ID: Announcing the immediate availability of Python 3.6.4 release candidate 1 and of Python 3.7.0 alpha 3! Python 3.6.4rc1 is the first release candidate for Python 3.6.4, the next maintenance release of Python 3.6. While 3.6.4rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). 3.6.4 is planned for final release on 2017-12-18 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.4rc1 and more information here: https://www.python.org/downloads/release/python-364rc1/ Python 3.7.0a3 is the third of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.7.0a4, is planned for 2018-01-08. You can find Python 3.7.0a3 and more information here: https://www.python.org/downloads/release/python-370a3/ -- Ned Deily nad at python.org -- [] From yselivanov.ml at gmail.com Wed Dec 6 11:27:39 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Wed, 6 Dec 2017 11:27:39 -0500 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: +1 from me. I first had an idea to give Ivan commit privileges when I was merging his PEP 526 implementation, so I think it's long overdue. Yury On Tue, Dec 5, 2017 at 8:00 PM, Guido van Rossum wrote: > I'd like to propose Ivan Levkivskyi as a new core committer. He's > (re-)written most of the typing.py module and will do so again for Python > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), > is co-author on several more (483, 561) and has been acknowledged in yet > others (557, 563). > > He is responsible for at least 16 commits in master. > > I have worked with him for a long time on typing.py and on mypy (where he is > a core dev) and I can vouch for him completely. > > -- > --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 guido at python.org Wed Dec 6 11:37:42 2017 From: guido at python.org (Guido van Rossum) Date: Wed, 6 Dec 2017 08:37:42 -0800 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: OK, let's make it so. It's been a long time since I initiated a new committer -- what has to happen next? I just flipped his committer bit on bpo, is there anything else that needs to happen? On Wed, Dec 6, 2017 at 8:27 AM, Yury Selivanov wrote: > +1 from me. I first had an idea to give Ivan commit privileges when I > was merging his PEP 526 implementation, so I think it's long overdue. > > Yury > > On Tue, Dec 5, 2017 at 8:00 PM, Guido van Rossum wrote: > > I'd like to propose Ivan Levkivskyi as a new core committer. He's > > (re-)written most of the typing.py module and will do so again for Python > > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, > 562), > > is co-author on several more (483, 561) and has been acknowledged in yet > > others (557, 563). > > > > He is responsible for at least 16 commits in master. > > > > I have worked with him for a long time on typing.py and on mypy (where > he is > > a core dev) and I can vouch for him completely. > > > > -- > > --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 guido at python.org Wed Dec 6 11:43:56 2017 From: guido at python.org (Guido van Rossum) Date: Wed, 6 Dec 2017 08:43:56 -0800 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: I think I figured it out -- I invited him to the python org on GitHub. Anything else? On Wed, Dec 6, 2017 at 8:37 AM, Guido van Rossum wrote: > OK, let's make it so. It's been a long time since I initiated a new > committer -- what has to happen next? I just flipped his committer bit on > bpo, is there anything else that needs to happen? > > On Wed, Dec 6, 2017 at 8:27 AM, Yury Selivanov > wrote: > >> +1 from me. I first had an idea to give Ivan commit privileges when I >> was merging his PEP 526 implementation, so I think it's long overdue. >> >> Yury >> >> On Tue, Dec 5, 2017 at 8:00 PM, Guido van Rossum >> wrote: >> > I'd like to propose Ivan Levkivskyi as a new core committer. He's >> > (re-)written most of the typing.py module and will do so again for >> Python >> > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, >> 562), >> > is co-author on several more (483, 561) and has been acknowledged in yet >> > others (557, 563). >> > >> > He is responsible for at least 16 commits in master. >> > >> > I have worked with him for a long time on typing.py and on mypy (where >> he is >> > a core dev) and I can vouch for him completely. >> > >> > -- >> > --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) > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Wed Dec 6 11:46:37 2017 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 6 Dec 2017 11:46:37 -0500 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: Someone needs to invite him to this list :-) On Dec 6, 2017 11:44 AM, "Guido van Rossum" wrote: > I think I figured it out -- I invited him to the python org on GitHub. > Anything else? > > On Wed, Dec 6, 2017 at 8:37 AM, Guido van Rossum wrote: > >> OK, let's make it so. It's been a long time since I initiated a new >> committer -- what has to happen next? I just flipped his committer bit on >> bpo, is there anything else that needs to happen? >> >> On Wed, Dec 6, 2017 at 8:27 AM, Yury Selivanov >> wrote: >> >>> +1 from me. I first had an idea to give Ivan commit privileges when I >>> was merging his PEP 526 implementation, so I think it's long overdue. >>> >>> Yury >>> >>> On Tue, Dec 5, 2017 at 8:00 PM, Guido van Rossum >>> wrote: >>> > I'd like to propose Ivan Levkivskyi as a new core committer. He's >>> > (re-)written most of the typing.py module and will do so again for >>> Python >>> > 3.7, he's the sole or primary author on several PEPs (526, 544, 560, >>> 562), >>> > is co-author on several more (483, 561) and has been acknowledged in >>> yet >>> > others (557, 563). >>> > >>> > He is responsible for at least 16 commits in master. >>> > >>> > I have worked with him for a long time on typing.py and on mypy (where >>> he is >>> > a core dev) and I can vouch for him completely. >>> > >>> > -- >>> > --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) >> > > > > -- > --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 mariatta.wijaya at gmail.com Wed Dec 6 11:57:52 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 6 Dec 2017 08:57:52 -0800 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: Please add Ivan to the Developer Log in Dev Guide, and he should subscribe to python-committers mailing list :) On Dec 6, 2017 8:44 AM, "Guido van Rossum" wrote: I think I figured it out -- I invited him to the python org on GitHub. Anything else? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Wed Dec 6 12:05:04 2017 From: nad at python.org (Ned Deily) Date: Wed, 6 Dec 2017 12:05:04 -0500 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: On Dec 6, 2017, at 11:57, Mariatta Wijaya wrote: > On Dec 6, 2017 8:44 AM, "Guido van Rossum" wrote: >> I think I figured it out -- I invited him to the python org on GitHub. Anything else? > Please add Ivan to the Developer Log in Dev Guide, and he should subscribe to python-committers mailing list :) It should all be here in the Devguide: https://devguide.python.org/coredev/#gaining-commit-privileges -- Ned Deily nad at python.org -- [] From victor.stinner at gmail.com Wed Dec 6 12:11:44 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 6 Dec 2017 18:11:44 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> Message-ID: Hi, Ok, thanks Ezio and David. I completed my list: https://github.com/vstinner/cpython_core_tutorial/blob/master/core_developer.rst#bug-tracker My initial question is to know if bug triage permission can be seen as a first "award" / "badge" to recognize that contributions of someone are useful. Contributions can only be made of code pull requests, or another "project" tightly coupled to CPython like the documentation, the development workflow, etc. My problem is now that the list of requirements is very long. It's like you should already practice triage for weeks before being seen as ready to get the triage power. So do you think that it's bad idea to use triage as an award? Or is it just a matter of adjusting requirements? I have a few people in mind that I would like to give them triage permission, but I don't know that they contributed much to the bug tracker. I don't expect them to be active on the bug tracker neither. Victor From rdmurray at bitdance.com Wed Dec 6 12:12:47 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Wed, 06 Dec 2017 12:12:47 -0500 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: <20171206171247.6FD1D1310029@webabinitio.net> On Wed, 06 Dec 2017 08:43:56 -0800, Guido van Rossum wrote: > I think I figured it out -- I invited him to the python org on GitHub. > Anything else? He needs to subscribe to this mailing list, and the developers.rst in the devguide repo should get an update. That's all I can think of, since ssh keys are now handled by github, but if there are other github things that need done I might not know them ;) Ah, it's all (or should be) in coredev.rst. I don't see anything else that needs done, though he should read that doc. --David From rdmurray at bitdance.com Wed Dec 6 12:41:47 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Wed, 06 Dec 2017 12:41:47 -0500 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> Message-ID: <20171206174151.669B3131002B@webabinitio.net> On Wed, 06 Dec 2017 18:11:44 +0100, Victor Stinner wrote: > Ok, thanks Ezio and David. I completed my list: > https://github.com/vstinner/cpython_core_tutorial/blob/master/core_developer.rst#bug-tracker s/loose/lose/ I would say your list comprises the skills for the "ideal triager" rather than "good triager", since I think someone can be a good triager without being and expert in a *all* of the skills you list in that section. I would expect a triager to develop facility with all those skills, but not necessarily to have them before they get granted privileges. (I'd say the second, fourth, fifth, and last are more or less the minimum to start with, although I'd drop the "which files should be updated to fix the issue" for that minimum set.) > My initial question is to know if bug triage permission can be seen as > a first "award" / "badge" to recognize that contributions of someone > are useful. Contributions can only be made of code pull requests, or > another "project" tightly coupled to CPython like the documentation, > the development workflow, etc. > > My problem is now that the list of requirements is very long. It's > like you should already practice triage for weeks before being seen as > ready to get the triage power. > > So do you think that it's bad idea to use triage as an award? Or is it > just a matter of adjusting requirements? Yes I think it is a bad idea to "use it" as an award. It is not an award, it is a functional set of privileges. It *can be* part of the on-boarding process for a contributor who eventually becomes a core dev, though, and in that path it functions as an award of sorts. > I have a few people in mind that I would like to give them triage > permission, but I don't know that they contributed much to the bug > tracker. I don't expect them to be active on the bug tracker neither. It they are not going to be active on the bug tracker, why do you want to give them triage permissions? If they haven't been active at least a little bit on the bug tracker, how do you know they are good candidate to be a triager? What do they need the privileges for? I'm not necessarily saying they shouldn't get them, I want to explore the why in order to inform this discussion. But, if you just want to give it to them as an award and for no other reason, I'd vote no. If you want a badge to give them, maybe we make up a badge ;) --David From victor.stinner at gmail.com Wed Dec 6 12:43:06 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 6 Dec 2017 18:43:06 +0100 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission Message-ID: Hi, To recognize the good contributions of Cheryl Sabella, I gave her the bug triage permission on bugs.python.org. (In practice, Ezio gave her the permission.) In the past, such "promotion" wasn't always advertized on python-committers, but my intent is to make our process more transparent and award people who deserve it! IMHO bug triage is the first step/milestone to become a core developer in the long term. FYI She pushed not less than 14 commits into the master branch since August, 2017. Congrats Cheryl! Victor From ezio.melotti at gmail.com Wed Dec 6 12:45:33 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Wed, 6 Dec 2017 18:45:33 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> Message-ID: On Wed, Dec 6, 2017 at 6:11 PM, Victor Stinner wrote: > Hi, > > Ok, thanks Ezio and David. I completed my list: > https://github.com/vstinner/cpython_core_tutorial/blob/master/core_developer.rst#bug-tracker > > My initial question is to know if bug triage permission can be seen as > a first "award" / "badge" to recognize that contributions of someone > are useful. Contributions can only be made of code pull requests, or > another "project" tightly coupled to CPython like the documentation, > the development workflow, etc. > > My problem is now that the list of requirements is very long. It's > like you should already practice triage for weeks before being seen as > ready to get the triage power. > > So do you think that it's bad idea to use triage as an award? Or is it > just a matter of adjusting requirements? > Depends on what you exactly mean with "award". Contributors might want to be able to edit more fields on the tracker, and the triage bit allows them to do it. This is beneficial for both the contributor and the other triagers, since they have one more helping hand. If the contributor knows what they are doing and they are helpful, we can "award" them with the triager bit, but this award shouldn't be given for unrelated accomplishments. Becoming a triager is a step to becoming a committer: we bestow them with some responsibility and trust, and if they do well, we can give them even more with the committer bit. Best Regards, Ezio Melotti > I have a few people in mind that I would like to give them triage > permission, but I don't know that they contributed much to the bug > tracker. I don't expect them to be active on the bug tracker neither. > > Victor From mariatta.wijaya at gmail.com Wed Dec 6 12:55:56 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 6 Dec 2017 09:55:56 -0800 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission In-Reply-To: References: Message-ID: Congrats Cheryl!! Thanks for your continued contributions! On Dec 6, 2017 9:43 AM, "Victor Stinner" wrote: Hi, To recognize the good contributions of Cheryl Sabella, I gave her the bug triage permission on bugs.python.org. (In practice, Ezio gave her the permission.) In the past, such "promotion" wasn't always advertized on python-committers, but my intent is to make our process more transparent and award people who deserve it! IMHO bug triage is the first step/milestone to become a core developer in the long term. FYI She pushed not less than 14 commits into the master branch since August, 2017. Congrats Cheryl! 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 ericsnowcurrently at gmail.com Wed Dec 6 13:01:12 2017 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 6 Dec 2017 11:01:12 -0700 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission In-Reply-To: References: Message-ID: On Wed, Dec 6, 2017 at 10:43 AM, Victor Stinner wrote: > To recognize the good contributions of Cheryl Sabella, I gave her the > bug triage permission on bugs.python.org. (In practice, Ezio gave her > the permission.) > > In the past, such "promotion" wasn't always advertized on > python-committers, but my intent is to make our process more > transparent and award people who deserve it! +1 > IMHO bug triage is the first step/milestone to become a core developer > in the long term. +1 > FYI She pushed not less than 14 commits into the master branch since > August, 2017. Nice! > Congrats Cheryl! A hearty +1! Keep up the good work, Cheryl. -eric From brett at python.org Wed Dec 6 13:16:42 2017 From: brett at python.org (Brett Cannon) Date: Wed, 06 Dec 2017 18:16:42 +0000 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: <20171206171247.6FD1D1310029@webabinitio.net> References: <20171206171247.6FD1D1310029@webabinitio.net> Message-ID: I just approve Ivan's subscription request to this list. And I know it's late, but a resounding +1 to this happening! On Wed, 6 Dec 2017 at 09:21 R. David Murray wrote: > On Wed, 06 Dec 2017 08:43:56 -0800, Guido van Rossum > wrote: > > I think I figured it out -- I invited him to the python org on GitHub. > > Anything else? > > He needs to subscribe to this mailing list, and the developers.rst in > the devguide repo should get an update. > > That's all I can think of, since ssh keys are now handled by github, > but if there are other github things that need done I might not know > them ;) > > Ah, it's all (or should be) in coredev.rst. I don't see anything else > that needs done, though he should read that doc. > > --David > _______________________________________________ > 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 mariatta.wijaya at gmail.com Wed Dec 6 13:20:35 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 6 Dec 2017 10:20:35 -0800 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: <20171206171247.6FD1D1310029@webabinitio.net> Message-ID: Welcome to the team, Ivan! Mariatta Wijaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Wed Dec 6 13:26:31 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 06 Dec 2017 10:26:31 -0800 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission In-Reply-To: References: Message-ID: <5A283657.60503@stoneleaf.us> On 12/06/2017 09:43 AM, Victor Stinner wrote: > Congrats Cheryl! Possibly a dumb question, but is Cheryl on this list? -- ~Ethan~ From ethan at stoneleaf.us Wed Dec 6 13:27:46 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 06 Dec 2017 10:27:46 -0800 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: <20171206171247.6FD1D1310029@webabinitio.net> Message-ID: <5A2836A2.6090904@stoneleaf.us> Ivan, Welcome! Glad to have you! -- ~Ethan~ From mariatta.wijaya at gmail.com Wed Dec 6 13:29:17 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 6 Dec 2017 10:29:17 -0800 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission In-Reply-To: <5A283657.60503@stoneleaf.us> References: <5A283657.60503@stoneleaf.us> Message-ID: Not dumb question. But I don't think Cheryl is on this list. not yet ;) On Dec 6, 2017 10:25 AM, "Ethan Furman" wrote: > On 12/06/2017 09:43 AM, Victor Stinner wrote: > > Congrats Cheryl! >> > > Possibly a dumb question, but is Cheryl on this list? > > -- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at gmail.com Wed Dec 6 13:30:56 2017 From: willingc at gmail.com (Carol Willing) Date: Wed, 6 Dec 2017 12:30:56 -0600 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission In-Reply-To: References: Message-ID: <06588D36-ECA8-445E-B9BC-8A7B68574C69@gmail.com> > On Dec 6, 2017, at 11:43 AM, Victor Stinner wrote: > > Hi, > > To recognize the good contributions of Cheryl Sabella, I gave her the > bug triage permission on bugs.python.org. (In practice, Ezio gave her > the permission.) Congrats Cheryl for the great work that you have done so far :D Also, thanks Ezio and Victor for recognizing the good work too. Warmly, Carol > > _______________________________________________ > 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 Wed Dec 6 13:45:10 2017 From: nad at python.org (Ned Deily) Date: Wed, 6 Dec 2017 13:45:10 -0500 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> Message-ID: <9BEC607C-F251-4C2C-B381-46F744C34AE0@python.org> On Dec 6, 2017, at 12:45, Ezio Melotti wrote: > Depends on what you exactly mean with "award". > Contributors might want to be able to edit more fields on the tracker, > and the triage bit allows them to do it. This is beneficial for both > the contributor and the other triagers, since they have one more > helping hand. If the contributor knows what they are doing and they > are helpful, we can "award" them with the triager bit, but this award > shouldn't be given for unrelated accomplishments. > Becoming a triager is a step to becoming a committer: we bestow them > with some responsibility and trust, and if they do well, we can give > them even more with the committer bit. In general, I agree with David's and Ezio's comments, in particular the idea that "bug triage" should not be an "award" nor a necessary first step towards being a committer. I think the skills necessary to be a good bug triager are not the same as being a good core developer. While the skill sets and experience level needed can overlap, I think we should consider the two roles as separate "career paths". In other words, some people would do a fine job as triager without wanting to be a core developer or contributing their own code patches, and that's fine. -- Ned Deily nad at python.org -- [] From tjreedy at udel.edu Wed Dec 6 14:37:56 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 6 Dec 2017 14:37:56 -0500 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: <9BEC607C-F251-4C2C-B381-46F744C34AE0@python.org> References: <20171120181245.6238C131001D@webabinitio.net> <9BEC607C-F251-4C2C-B381-46F744C34AE0@python.org> Message-ID: <6abadf98-6b2f-c51a-fe1c-3cd897dd1bd6@udel.edu> On 12/6/2017 1:45 PM, Ned Deily wrote: > On Dec 6, 2017, at 12:45, Ezio Melotti wrote: >> Depends on what you exactly mean with "award". >> Contributors might want to be able to edit more fields on the tracker, >> and the triage bit allows them to do it. This is beneficial for both >> the contributor and the other triagers, since they have one more >> helping hand. If the contributor knows what they are doing and they >> are helpful, we can "award" them with the triager bit, but this award >> shouldn't be given for unrelated accomplishments. >> Becoming a triager is a step to becoming a committer: we bestow them >> with some responsibility and trust, and if they do well, we can give >> them even more with the committer bit. > > In general, I agree with David's and Ezio's comments, in particular the idea that "bug triage" should not be an "award" nor a necessary first step towards being a committer. I think the skills necessary to be a good bug triager are not the same as being a good core developer. While the skill sets and experience level needed can overlap, I think we should consider the two roles as separate "career paths". In other words, some people would do a fine job as triager without wanting to be a core developer or contributing their own code patches, and that's fine. I agree. Database maintenance is a separate skill and interest from the 3 skills of patch writing, reviewing, and merging. Committers need to be able to maintain and ultimately close the issues they work on, but need not engage in general tracker gardening. tjr From levkivskyi at gmail.com Wed Dec 6 15:27:17 2017 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Wed, 6 Dec 2017 21:27:17 +0100 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: <20171206171247.6FD1D1310029@webabinitio.net> Message-ID: Thank you Mariatta, Ethan, Eric, Guido, and everyone! I am overwhelmed by all the positive comments! I am so glad to be the part of the team and looking forward to make more contributions. (Will start right now form polishing PEP 560 and PEP 562 implementation :-) -- Ivan On 6 December 2017 at 19:20, Mariatta Wijaya wrote: > Welcome to the team, Ivan! > > Mariatta Wijaya > > > _______________________________________________ > 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 zachary.ware+pydev at gmail.com Wed Dec 6 15:37:19 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Wed, 6 Dec 2017 14:37:19 -0600 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: <20171206171247.6FD1D1310029@webabinitio.net> Message-ID: On Wed, Dec 6, 2017 at 2:27 PM, Ivan Levkivskyi wrote: > Thank you Mariatta, Ethan, Eric, Guido, and everyone! > I am overwhelmed by all the positive comments! > > I am so glad to be the part of the team and looking forward to make more > contributions. > (Will start right now form polishing PEP 560 and PEP 562 implementation :-) Welcome to the team, Ivan :) -- Zach From victor.stinner at gmail.com Wed Dec 6 16:43:57 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 6 Dec 2017 22:43:57 +0100 Subject: [python-committers] Sanyam Khurana has been promoted to get bug triage permission Message-ID: Hi, To recognize the good contributions of Sanyam Khurana, I gave him the bug triage permission on bugs.python.org. (In practice, Ezio gave him the permission.) He already commited 9 changes into the master branch since April, 2017. Congrats Sanyam! Victor From victor.stinner at gmail.com Wed Dec 6 17:06:50 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 6 Dec 2017 23:06:50 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: <20171206174151.669B3131002B@webabinitio.net> References: <20171120181245.6238C131001D@webabinitio.net> <20171206174151.669B3131002B@webabinitio.net> Message-ID: 2017-12-06 18:41 GMT+01:00 R. David Murray : > s/loose/lose/ Oops, fixed, thanks. >> So do you think that it's bad idea to use triage as an award? Or is it >> just a matter of adjusting requirements? > > Yes I think it is a bad idea to "use it" as an award. It is not an > award, it is a functional set of privileges. It *can be* part of the > on-boarding process for a contributor who eventually becomes a core dev, > though, and in that path it functions as an award of sorts. My initial problem is the huge gap between "regular contributor" and "core developer". Currently, we have a single huge step which is very hard to climb. I'm trying to create new smaller steps and describe each step. The goal is to have a clear path with requirements for each step. Before becoming a core developer, I see bug triage as a first step. I already proposed on this step to add a second step before core developer: getting a mentor. Newcomer => contributor => bug triage => getting a mentor => core developer It would help to have sub-steps, but it can be adjusted later ;-) >> I have a few people in mind that I would like to give them triage >> permission, but I don't know that they contributed much to the bug >> tracker. I don't expect them to be active on the bug tracker neither. > > It they are not going to be active on the bug tracker, why do you want > to give them triage permissions? If they haven't been active at least > a little bit on the bug tracker, how do you know they are good candidate > to be a triager? > > What do they need the privileges for? I'm not necessarily saying they > shouldn't get them, I want to explore the why in order to inform this > discussion. But, if you just want to give it to them as an award and > for no other reason, I'd vote no. If you want a badge to give them, > maybe we make up a badge ;) It's not because you give the commit bit contributors that they will become very active. My expectation is more than giving more priviledge would motive them to become move active. A contributor without the triage priviledge cannot triage bugs... I'm not sure that "an award" is the best word sorry. Mariatta already corrected me when I wrote that becoming a core developer gives more power, she replied that it gives more *responsabilities*. It's the same here :-) By the way, my final goal is to get more people aboard to better scale horizontal for the Python workflow ;-) I suck at many things in Python, and I'm very happy to see new "faces" helping on areas where I'm unable to help. For example, Cheryl Sabella is working on the IDLE application, whereas I don't know much about Tkinter nor IDLE. But IDLE is a popular application since it's installed with Python, and used by teachers. He also likes when other people help on the documentation since it's a big task and we never have enough hands to work on the doc! Does it make any sense to you? :-) Victor From victor.stinner at gmail.com Wed Dec 6 17:17:33 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 6 Dec 2017 23:17:33 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> Message-ID: 2017-12-06 18:45 GMT+01:00 Ezio Melotti : > Depends on what you exactly mean with "award". See my reply to David. > If the contributor knows what they are doing and they > are helpful, we can "award" them with the triager bit, but this award > shouldn't be given for unrelated accomplishments. My problem is that we don't have a long list of "awards" in Python: the triage bit and the commit bit... I had some ideas to create badges, but before I come with something concrete, I'm trying to build something with what we already have ;-) > Becoming a triager is a step to becoming a committer: we bestow them > with some responsibility and trust, and if they do well, we can give > them even more with the committer bit. Oh, this is exactly my intent. Sorry if I picked the wrong words :-p I promoted Cheryl Sabella and Sanyam Khurana to encourage them to become even more active ;-) Victor From victor.stinner at gmail.com Wed Dec 6 17:23:46 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 6 Dec 2017 23:23:46 +0100 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission In-Reply-To: References: Message-ID: 2017-12-06 23:07 GMT+01:00 Cheryl Sabella : > Wow, this is a shock! I'm sorry, maybe I had to warn you before? ;-) > Thank you, Victor, Ezio, and everyone else. This is > such an amazing and welcoming community, so thank you for letting me be a > part of it. You're welcome. Victor From antoine at python.org Wed Dec 6 17:35:41 2017 From: antoine at python.org (Antoine Pitrou) Date: Wed, 6 Dec 2017 23:35:41 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> <20171206174151.669B3131002B@webabinitio.net> Message-ID: Le 06/12/2017 ? 23:06, Victor Stinner a ?crit?: > > My initial problem is the huge gap between "regular contributor" and > "core developer". Currently, we have a single huge step which is very > hard to climb. I wonder: is this the right question to ask? There are contributors who will never become core developers. It's not a failure. How many of us actually hoped or expected to become a core developer when they started contributing? The real issue is not that the step is hard to climb, but that it is hard to get people interested in climbing that step (and continue being active afterwards, even though the step has been climbed). It is to get people interested in the tasks and responsibilities (sometimes annoyances) of being a core developer. > It's not because you give the commit bit contributors that they will > become very active. My expectation is more than giving more priviledge > would motive them to become move active. I don't think the latter works any better than the former :-) > A contributor without the triage priviledge cannot triage bugs... Yes, so it's more a question of giving them the tools necessary to do what they want to do. Not of giving them an award or a privilege :-) Regards Antoine. From victor.stinner at gmail.com Wed Dec 6 18:00:22 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 7 Dec 2017 00:00:22 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> <20171206174151.669B3131002B@webabinitio.net> Message-ID: 2017-12-06 23:35 GMT+01:00 Antoine Pitrou : > The real issue is not that the step is hard to climb, but that it is > hard to get people interested in climbing that step (and continue being > active afterwards, even though the step has been climbed). It is to get > people interested in the tasks and responsibilities (sometimes > annoyances) of being a core developer. What do you propose? Victor From victor.stinner at gmail.com Wed Dec 6 18:17:04 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 7 Dec 2017 00:17:04 +0100 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity Message-ID: Hi, I wrote a quick & dirty parser to compute statistics on *new* CPython core developer per year using the following page as data: https://devguide.python.org/developers/ 2007: 15 2008: 19 2009: 11 2010: 20 2011: 12 2012: 9 2013: 4 2014: 10 2015: 2 2016: 5 2017: 2 Compare these numbers to St?phane Wirtel's statistics on pull requests: https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests => Number of active core developerson on GitHub pull requests: 27 (stats from February 2017 to October 2017) (I'm not sure of the meaning of this number, it's the number of core developer who authored pull requests, I don't think that it counts core developers who only made reviews.) If you look at the size of the source code, it's still growing constanly since 1990: https://www.openhub.net/p/python/ 2007: around 783k lines 2010: around 683k lines 2013: around 800k lines 2015: around 875k lines 2017: around 973k lines The number of bugs is also constanly growing. Statistics on bugs since 2011: https://bugs.python.org/issue?@template=stats 2011: around 2500 open issues 2013: around 4000 open issues 2015: around 5000 open issues 2017: around 6200 open issues The size of the CPython project is constantly growing as its complexity (technical debt? what is this? :-)), but the growth of core developers is slowing down. I do consider that we need more people to handle the growing number of issues and pull requests, so the question is now how to find and "hire" (sorry, promote) them ;-) Maybe we have a problem with mentoring. Maybe the CPython code base became too hard to train newcomers? Maybe we are too conservative? I don't know. Victor From senthil at uthcode.com Wed Dec 6 18:25:11 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 6 Dec 2017 15:25:11 -0800 Subject: [python-committers] Sanyam Khurana has been promoted to get bug triage permission In-Reply-To: References: Message-ID: Congratulations, and Welcome Sanyam!. Thank you, and keep up with your good work. On Wed, Dec 6, 2017 at 1:43 PM, Victor Stinner wrote: > Hi, > > To recognize the good contributions of Sanyam Khurana, I gave him the > bug triage permission on bugs.python.org. (In practice, Ezio gave him > the permission.) > > He already commited 9 changes into the master branch since April, 2017. > > Congrats Sanyam! > > 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 Wed Dec 6 18:39:33 2017 From: antoine at python.org (Antoine Pitrou) Date: Thu, 7 Dec 2017 00:39:33 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> <20171206174151.669B3131002B@webabinitio.net> Message-ID: <3ced73ee-a1e8-fd4b-5afe-b3d9ab7e534c@python.org> Le 07/12/2017 ? 00:00, Victor Stinner a ?crit?: > 2017-12-06 23:35 GMT+01:00 Antoine Pitrou : >> The real issue is not that the step is hard to climb, but that it is >> hard to get people interested in climbing that step (and continue being >> active afterwards, even though the step has been climbed). It is to get >> people interested in the tasks and responsibilities (sometimes >> annoyances) of being a core developer. > > What do you propose? I would like to propose the following postulate: given a certain number of contributors, only a small fraction of them (for example 10%) is actually interested in becoming a core developer and handling the responsibilities thereof. We cannot really increase that fraction as it is tied to personal factors (time, motivation). Therefore, we should strive to attract more contributors in the hope that the number of core developers selected out of those contributors will also increase. Regards Antoine. From antoine at python.org Wed Dec 6 18:52:42 2017 From: antoine at python.org (Antoine Pitrou) Date: Thu, 7 Dec 2017 00:52:42 +0100 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity In-Reply-To: References: Message-ID: <9484fdff-95bc-a1b0-958f-96447258f956@python.org> Le 07/12/2017 ? 00:17, Victor Stinner a ?crit?: > > Maybe we have a problem with mentoring. Maybe the CPython code base > became too hard to train newcomers? Maybe we are too conservative? I > don't know. The language moved at a faster pace back then (especially with Python 3), which made it easier to find ways to contribute without getting into boring or overly tedious topics. Also, I think its image is simply changing. 10 years ago, Python still stood out as something cool and a bit special. Now it's regarded as established and mature, and it certainly changes its attractivity among the kind of people who are keen to do volunteer contributions to free / open source software. Can this be reversed? I don't know. Regards Antoine. From steve at pearwood.info Wed Dec 6 19:19:28 2017 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 7 Dec 2017 11:19:28 +1100 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity In-Reply-To: References: Message-ID: <20171207001927.GZ22248@ando.pearwood.info> On Thu, Dec 07, 2017 at 12:17:04AM +0100, Victor Stinner wrote: > If you look at the size of the source code, it's still growing > constanly since 1990: > https://www.openhub.net/p/python/ > > 2007: around 783k lines > 2010: around 683k lines What happened between 2007 and 2010 that the source shrank by nearly 13%? -- Steve From barry at python.org Wed Dec 6 19:31:43 2017 From: barry at python.org (Barry Warsaw) Date: Wed, 6 Dec 2017 19:31:43 -0500 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity In-Reply-To: References: Message-ID: On Dec 6, 2017, at 18:17, Victor Stinner wrote: > I wrote a quick & dirty parser to compute statistics on *new* CPython > core developer per year using the following page as data: > https://devguide.python.org/developers/ > > 2007: 15 > 2008: 19 > 2009: 11 > 2010: 20 > 2011: 12 > 2012: 9 > 2013: 4 > 2014: 10 > 2015: 2 > 2016: 5 > 2017: 2 Thanks for the analysis. Let?s do everything we can to get some of these newer core devs to the Language Summit in 2018! -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 victor.stinner at gmail.com Wed Dec 6 19:48:16 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 7 Dec 2017 01:48:16 +0100 Subject: [python-committers] Promote Julien Palard as core developer Message-ID: Hi, I propose to promote Julien Palard as a core developer. Julien Palard is leading the french translation of the Python documentation since 2 or 3 years. He spent a lot of time to try to get this translation online. Since he was unlucky on the python-ideas mailing list, I convinced him to write down a PEP. He wrote it with Naoki INADA (who is translated the documentation to Japanese) and me. It wasn't easy to write the PEP and get it approved: it took almost 1 year and a half! The PEP 545 was approved and implemented in Python 3.7! https://www.python.org/dev/peps/pep-0545/ Thanks to Julien (and others), translated documentations are now online at: https://docs.python.org/fr/ -- French https://docs.python.org/ja/ -- Japanese See also the What's New in Python 3.7 entry: https://docs.python.org/dev/whatsnew/3.7.html#documentation Julien spent a lot of time to fix a lot of various issues in the documentation, the docsbuild-scripts project used to build the CPython documentation, Sphinx, etc. to be able to translate properly the documentation. For me, the documentation and the docsbuild-scripts project are tightly coupled to the CPython project. Last june, I even asked to give the commit bit to Julien on the https://github.com/python/docsbuild-scripts/ project on this list, since I expected that this project was part of CPython (it isn't, it's another "team" on GitHub, if I understood correctly) :-) In the meanwhile, Julien became a "core developer" on this project as well. He also worked closely with the Python infra team to fix a few bugs when the translated documentation was published at python.org. To come back to CPython itself, Julien Palard already got 18 commits merged into the master branch since January 2016: 11 before GitHub ("patch by Julien Palard") + 7 since CPython migrated to GitHub ("Julien Palard" author). Most of his commits are related to the Python documentation content and tooling to build the documentation. He fixed "bugs" in the documentation, to clarify some documentation. Giving him the commit bit would ease his work, since too few people are looking at these areas of the code. When I reviewed his patches, they are usually good after one or two iterations, and Julien welcomes criticism. I know that Julien doesn't have the typical profile of core developers, only or mostly contribute to the code: Julien is currently focused on the doculmentation. But I believe (because he told me so ;-)) that Julien will slowly contribute to other areas of the code, once he will feel more confortable, and I may guide him in the code if needed. I think that many of us started to contribute to a project on its documentation ;-) I don't think that he needs an official menthor since he already knows well the CPython workflow, and he knows how to ask questions if needed ;-) Promoting Julien is part of my global idea/project of trying to recognize more contributions which are not strictly code, but as useful or even more useful than code! Python documentation is part of Python's success. I was told many times that Python has a good documentation, it's nice to hear that ! IMHO reducing CPython to its C and Python code is wrong and nor fair, CPython made of much more "sub-projects". Victor From willingc at gmail.com Wed Dec 6 20:20:18 2017 From: willingc at gmail.com (Carol Willing) Date: Wed, 6 Dec 2017 19:20:18 -0600 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: <3ced73ee-a1e8-fd4b-5afe-b3d9ab7e534c@python.org> References: <20171120181245.6238C131001D@webabinitio.net> <20171206174151.669B3131002B@webabinitio.net> <3ced73ee-a1e8-fd4b-5afe-b3d9ab7e534c@python.org> Message-ID: > On Dec 6, 2017, at 5:39 PM, Antoine Pitrou wrote: > > > Therefore, we should strive to attract more contributors in the hope > that the number of core developers selected out of those contributors > will also increase. > Some very good discussion and points are being made here. Bravo to Victor (and Ezio as well as others) for taking the initiative to foster contributors and recognizing / thanking them for their contributions. I think what Antoine pointed out about having the tools / permissions to be effective at contributing in whatever capacity is also very important. Having recognition without the tools or tools without recognition isn't optimal. Having both leads to the greatest likelihood for future contributions from an individual. Feeling valued and being effective are both critical to keeping a contributor engaged in the community. > _______________________________________________ > 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 Wed Dec 6 20:41:02 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 7 Dec 2017 11:41:02 +1000 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity In-Reply-To: <20171207001927.GZ22248@ando.pearwood.info> References: <20171207001927.GZ22248@ando.pearwood.info> Message-ID: On 7 December 2017 at 10:19, Steven D'Aprano wrote: > On Thu, Dec 07, 2017 at 12:17:04AM +0100, Victor Stinner wrote: > >> If you look at the size of the source code, it's still growing >> constanly since 1990: >> https://www.openhub.net/p/python/ >> >> 2007: around 783k lines >> 2010: around 683k lines > > What happened between 2007 and 2010 that the source shrank by nearly > 13%? My guess would be that it's a consequence of Python 3 becoming the default branch. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From berker.peksag at gmail.com Wed Dec 6 22:36:41 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Thu, 7 Dec 2017 06:36:41 +0300 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: <20171120181245.6238C131001D@webabinitio.net> <20171206174151.669B3131002B@webabinitio.net> Message-ID: On Thu, Dec 7, 2017 at 1:06 AM, Victor Stinner wrote: > A contributor without the triage priviledge cannot triage bugs... I don't see this as a big problem. There are many ways to do issue triaging (you need to follow python-checkins, know how to use tools like 'git blame' etc.) so I don't think it's possible document every single step in the devguide. The best way to learn how to triage an issue is to follow core developers closely. That's what I did when I was a contributor. Giving people an 'award' early may risk introducing unnecessary noise on tracker. I understand that it's not end of the world, but note that every wrong action needs to be reverted by another volunteer. I'd prefer having less triagers if we are going to end up with messages like: * This issue is open for N years so I think it can be closed (Age of an issue is not important) * This issue appears to be fixed. Closing. (They didn't explain why they think it's fixed. They have to find the commit that fixed the issue or upload a simple script that shows the issue is fixed or use an existing script to show that it's fixed) --Berker From berker.peksag at gmail.com Wed Dec 6 22:49:21 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Thu, 7 Dec 2017 06:49:21 +0300 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity In-Reply-To: References: Message-ID: On Thu, Dec 7, 2017 at 2:17 AM, Victor Stinner wrote: > Hi, > > I wrote a quick & dirty parser to compute statistics on *new* CPython > core developer per year using the following page as data: > https://devguide.python.org/developers/ > > 2007: 15 > 2008: 19 > 2009: 11 > 2010: 20 > 2011: 12 > 2012: 9 > 2013: 4 > 2014: 10 > 2015: 2 > 2016: 5 > 2017: 2 > > Compare these numbers to St?phane Wirtel's statistics on pull requests: > https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests > > => Number of active core developerson on GitHub pull requests: 27 > (stats from February 2017 to October 2017) > (I'm not sure of the meaning of this number, it's the number of core > developer who authored pull requests, I don't think that it counts > core developers who only made reviews.) Is there an easy way to merge the first two stats? It would be interesting to see a table like this: Number of active core developers | Year of their first commit 4 | 2012 3 | 2014 ... --Berker From ncoghlan at gmail.com Thu Dec 7 03:48:32 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 7 Dec 2017 18:48:32 +1000 Subject: [python-committers] Promote Julien Palard as core developer In-Reply-To: References: Message-ID: On 7 December 2017 at 10:48, Victor Stinner wrote: > Promoting Julien is part of my global idea/project of trying to > recognize more contributions which are not strictly code, but as > useful or even more useful than code! Python documentation is part of > Python's success. I was told many times that Python has a good > documentation, it's nice to hear that ! IMHO reducing CPython to its C > and Python code is wrong and nor fair, CPython made of much more > "sub-projects". +1 from me for giving docs-focused folks commit access! As the saying goes, "For most users, if it isn't documented, it may as well not exist" :) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From zachary.ware+pydev at gmail.com Thu Dec 7 11:18:53 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Thu, 7 Dec 2017 10:18:53 -0600 Subject: [python-committers] Promote Julien Palard as core developer In-Reply-To: References: Message-ID: On Thu, Dec 7, 2017 at 2:48 AM, Nick Coghlan wrote: > On 7 December 2017 at 10:48, Victor Stinner wrote: >> Promoting Julien is part of my global idea/project of trying to >> recognize more contributions which are not strictly code, but as >> useful or even more useful than code! Python documentation is part of >> Python's success. I was told many times that Python has a good >> documentation, it's nice to hear that ! IMHO reducing CPython to its C >> and Python code is wrong and nor fair, CPython made of much more >> "sub-projects". > > +1 from me for giving docs-focused folks commit access! As the saying > goes, "For most users, if it isn't documented, it may as well not > exist" :) +1 here too, for the same reasons. Also, I've worked with Julien on a couple of issues and had nothing but good experience with him. -- Zach From ethan at stoneleaf.us Thu Dec 7 11:29:05 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 07 Dec 2017 08:29:05 -0800 Subject: [python-committers] Promote Julien Palard as core developer In-Reply-To: References: Message-ID: <5A296C51.3000606@stoneleaf.us> On 12/06/2017 04:48 PM, Victor Stinner wrote: > I propose to promote Julien Palard as a core developer. > I know that Julien doesn't have the typical profile of core > developers, only or mostly contribute to the code: Julien is currently > focused on the doculmentation. Good documentation is hard. +1 to bring Julien Palard in! -- ~Ethan~ From mariatta.wijaya at gmail.com Thu Dec 7 11:58:01 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Thu, 7 Dec 2017 08:58:01 -0800 Subject: [python-committers] Promote Julien Palard as core developer In-Reply-To: <5A296C51.3000606@stoneleaf.us> References: <5A296C51.3000606@stoneleaf.us> Message-ID: Agree. +1! Mariatta Wijaya On Thu, Dec 7, 2017 at 8:29 AM, Ethan Furman wrote: > On 12/06/2017 04:48 PM, Victor Stinner wrote: > > I propose to promote Julien Palard as a core developer. >> > > I know that Julien doesn't have the typical profile of core >> developers, only or mostly contribute to the code: Julien is currently >> focused on the doculmentation. >> > > Good documentation is hard. +1 to bring Julien Palard in! > > -- > ~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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Thu Dec 7 12:17:47 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Thu, 7 Dec 2017 09:17:47 -0800 Subject: [python-committers] Sanyam Khurana has been promoted to get bug triage permission In-Reply-To: References: Message-ID: Congrats Sanyam! Thanks for your continued contributions :) Mariatta Wijaya On Wed, Dec 6, 2017 at 3:25 PM, Senthil Kumaran wrote: > Congratulations, and Welcome Sanyam!. > > Thank you, and keep up with your good work. > > > > On Wed, Dec 6, 2017 at 1:43 PM, Victor Stinner > wrote: > >> Hi, >> >> To recognize the good contributions of Sanyam Khurana, I gave him the >> bug triage permission on bugs.python.org. (In practice, Ezio gave him >> the permission.) >> >> He already commited 9 changes into the master branch since April, 2017. >> >> Congrats Sanyam! >> >> 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/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Dec 7 13:00:31 2017 From: barry at python.org (Barry Warsaw) Date: Thu, 7 Dec 2017 13:00:31 -0500 Subject: [python-committers] Official python-dev docker images Message-ID: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> As part of the importlib_resources skunkworks project Brett and I have been working on (just announced), we?ve also put together a nice Docker image that we?re using for our automated testing. This image is based on Ubuntu 16.04 and provides the latest stable releases of Python 2.7, and 3.4-3.6, along with a mostly up-to-date git checkout of master, currently Python 3.7 of course. Once 3.7 is released to beta, we intend to track its release tarballs too. We also install a few other commonly needed tools, like pip, git, unzip, wget, mypy, and tox. Here?s the project repo: https://gitlab.com/python-devs/ci-images Huge shout out to Abhilash Raj who helped us clean up and compactify the image, and also for setting up automated publishing to quay.io. In case you weren?t aware, Abhilash is who I passed GNU Mailman project leadership to, so he has a lot of Python experience, and a ton of expertise in the image space. He?s an amazing amount of work to improve the quality of this image! Brett and I want to promote this more widely within the Python community as the ?official Python Docker image? that projects can use in their own testing environments, or base their own images on it. We wanted to give you guys a heads up first to get your feedback, and maybe thoughts on the best places to promote this, e.g. on the python.org website or other places. We welcome your participation too of course! I?m happy to give write access to the project to any Python committer who wants to help. Cheers, -Barry, Brett, Abhilash -------------- 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 victor.stinner at gmail.com Thu Dec 7 13:01:50 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 7 Dec 2017 19:01:50 +0100 Subject: [python-committers] RFC: Process to become a core developer Message-ID: Hi, I'm working on a process to describe how a contributor becomes a core developer. The purpose is to be transparent, list "requirements" and responsabilities to the contributor, and have written rules to help to take a fair decision. This document is a draft. I chose to post it on python-committers. I expect that we would have to iterate on it multiple times until we can reach a consensus to agree on the process. While the process has many details, it must be seen more as a guideline than strict rules. Note: I'm trying to avoid gender to be inclusive when mentioning a contributor by using "they" or "their". I'm not sure that it's correct in english, since english is not my first language. Is "they" acceptable to identify a single contributor, or is it restricted to the plural form (contributors)? == Introduction == The overall goal is to get more active developers working on Python to better scale horizontally: get more reviews to get better changes. The code quality is expected to be enhanced: more eyes on reviews should help to catch bugs earlier. Another less important goal is to speed up the Python development IMHO the current blocker issue is that it is too hard to become a core developer. While becoming a core developer is not required to contribute, in my experience, core developers feel more involved and better recognized for their work. Core developer first means becoming responsible of a change: maintain the code/documentation and handle any potential regression. Long term commitment and good quality reviews are also expected from core developers. The blocker issue can be explained by the very high step that should be climed at once to become a core developer. The contributor responsibilities changes at once from "no power" to "can do anything on any part of the project". A promotion is decided with a vote. If a voter doesn't know the contributor, it can be very stressful to take a decision. Building a trust relationship takes time and is not currently formalized by a process. This process is trying to address these issues. I propose to formalize a process to promote a contributor from the early newcomer step to the final core developer step. The process is made of multiple steps to help the contributor to estimate their own progress. Mentoring becomes required by the process and is a major part of the whole process. While the process explains how to "clim" steps, going backward now becomes part of the process, it is not seen as a failure but as a normal and expected change under certain conditions. The final vote to promote a contributor as a core developer is expected to become more natural and simpler. The voters are expected to know better the future candidate. == Process Steps == I propose the following steps to become a core developer: * Step 0: Newcomer * Step 1: Contributor * Step 2: Bug triage permission * Step 3: Mentoree. * Step 4: Core developer == Step 0: Newcomer == The first step is to start as a newcomer. Usually, newcomers are following the Python development without actively contributing. == Step 1: Contributor == I consider that newcomers become automatically contributors as soon as they post their first comment on the bug tracker, comment on a pull request, or a pull request. Their is no manual validation, nor additional privilege. It's just a thin distinction with a newcomer. At this step, it becomes interesting to start reading the Python Developer Guide: http://devguide.python.org/ == Step 2: Bug Triage Permission == Once a contributor becomes active enough, a core developer can propose to give the bug triage permission to the contributor. The contributors may ask themself to give this permission. The level of activity is not strictly defined, since it depends on the kind of contributions and their quality. The core developer is responsabile to estimate this. There is no formal vote to give the bug triage permission. The core developer becomes responsible of the promotion. In practice, core developers are free to discuss together ;-) Getting the bug triage permission gives more responsabilities to the contributor: the bug tracker should not be misused to not lost useful information. Taking a decision on an issue requires a certain level of knowledege of the Python development. I propose that the contributor gets a mentor during one month. The role of the mentor is to answer to any question of the mentoree, and help them to take decisions if needed. The mentor is not expected to watch closely what the contributor does on the bug tracker. If the contributor misuses the bug tracker, the mentor (or another core developer) should help the contributor to adjust their behaviour. If the contributor continue to abuse the bug tracker or misbehaves, the permission is removed and the contributor moves back to the previous step. This step is the opportunity to know each other, begin to create a trust relationship. Required skills for the contributor: * Be active on the Python project: bug tracker, pull requests and/or mailing lists like python-ideas and python-dev. There is no minimum number of contributions: it's not a matter of quantity, but more a matter of quality and the kind of contributions. * Be nice, police and respectful. * Know what they are talking about, and explain their reasoning well. Skills which are nice to have, but not required: * Know how to triage bugs. If the contributor doesn't know that, I consider that the role of the mentor is to explain this (using the devguide documentation). * Read the Python Developer Guide. This step is also a first milestone to measure the contrbutor involvment in the Python project, to later be able to estimate their "longterm commitement". == Step 3: Getting a mentor == Python project is big and has a long history. Contributors need a referrer to guide them in this wild and dangerous (!) project, and in the development workflow. The role of the mentor is to answer to contributors questions and review their work. The role is not to become the single gatekeeper merging all contributions of one specific contributor. It's perfectly fine if the mentor is unable to review a pull request, just help to find an appropriate reviewer in this case. This step is a second opportunity to build a trust relationship, maybe already started at the previous step with the same mentor. Required contributor skills: * Be active on the Python project: I would like to say "still" be active on the Python project, which is another proof of the contributor commitement in the project * Sign the CLA: at some point, getting changes merged into Git becomes mandatory, and so the CLA must be signed. * Find a mentor. Required mentor skills: * Be a core contributor. * Be available at least during one whole month. * Follow the contributor: must get an update at least once a week, especially if the contributor doesn't show up. Obviously, it's better if the contributor interest areas match with the mentor interest areas ;-) (... Maybe later we may change the process to allow non-core developers to become mentors, but I'm not sure about of this yet ...) If the contributor becomes unavailable, it's fine, it's just a small step backward, until they become available again. If the mentor becomes unavailable, maybe a different mentor can continue the process, otherwise the contributor goes back to the previous step. == Step 4: Core Developer == Once the mentor or another core developer consider that the contributor is mature enough to be promoted, a vote is organized on the python-committers mailing list. The contributor skills and contributions should be listed. Usually, any negative vote becomes a veto which blocks the promotion. While a few votes were negative in the past, I hope that this new formalized process would make the vote more natural and limit the "risk" of negative votes. Requirements to become a core developer: * Be nice and respectful * Humility * Long term commitement * Reviews * Know the CPython workflow * Know the CPython lifecycle * Know the Python C API specific issues, for contributors working on the C code * Good quality patches I described these requirements in detail at: http://cpython-core-tutorial.readthedocs.io/en/latest/core_developer.html#requirements-to-become-a-core-developer Becoming a core developer involves getting more responsabilities: * The core developer becomes the "owner" of a merged change: maintain the code and handle any potential regression * Review pull requests * Triage bugs The newly promoted core developer will followed by a mentor during one month until they become confortable enough. Obviously, the mentoring can be extended if needed. If the result of the promotion vote is negative, it's ok, move back to the previous step, and retry later. Usually the vote can be retried 6 months later, time spent to address lacking skills (maybe with a mentor). Hum, it seems like the contributor has been promoted: congratulations and welcome aboard! Victor From barry at python.org Thu Dec 7 13:03:19 2017 From: barry at python.org (Barry Warsaw) Date: Thu, 7 Dec 2017 13:03:19 -0500 Subject: [python-committers] Official python-dev docker images In-Reply-To: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> References: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> Message-ID: <5B693E66-3BB8-4926-A88E-C5F85D4C27FB@python.org> On Dec 7, 2017, at 13:00, Barry Warsaw wrote: > He?s an amazing amount of work to improve the quality of this image! Um, let me rephrase :) He?s done an amazing amount of work to improve the quality of this image! -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 ethan at stoneleaf.us Thu Dec 7 13:11:14 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 07 Dec 2017 10:11:14 -0800 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: References: Message-ID: <5A298442.7000107@stoneleaf.us> On 12/07/2017 10:01 AM, Victor Stinner wrote: > Note: I'm trying to avoid gender to be inclusive when mentioning a > contributor by using "they" or "their". I'm not sure that it's correct > in english, since english is not my first language. Is "they" > acceptable to identify a single contributor, or is it restricted to > the plural form (contributors)? "They" and "their" have been used as gender-neutral, singular pronouns for centuries. It can sound odd to those of us not accustomed to hearing it, but it is correct. -- ~Ethan~ From antoine at python.org Thu Dec 7 13:21:02 2017 From: antoine at python.org (Antoine Pitrou) Date: Thu, 7 Dec 2017 19:21:02 +0100 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: References: Message-ID: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> Le 07/12/2017 ? 19:01, Victor Stinner a ?crit?: > > IMHO the current blocker issue is that it is too hard to become a core > developer. I don't think so. It should not be harder than it was in 2010, yet we are promoting way less core developers than we did. See previous discussion. > A promotion is decided with a vote. If a > voter doesn't know the contributor, it can be very stressful to take a > decision. If someone doesn't know the contributor, they can simply say so and abstain from voting. It's what we usually do already: there are 150+ core developers and only a few of them vote when a new core developer is proposed. So this is not a problem in practice. > == Step 2: Bug Triage Permission == > > Once a contributor becomes active enough, a core developer can propose > to give the bug triage permission to the contributor. It sounds like you are not taking into account what was said by various people during the previous discussion. > == Step 3: Getting a mentor == > > Python project is big and has a long history. Contributors need a > referrer to guide them in this wild and dangerous (!) project, and in > the development workflow. Perhaps you are overdoing this? :-) > Required mentor skills: > > * Be a core contributor. > * Be available at least during one whole month. > * Follow the contributor: must get an update at least once a week, > especially if the contributor doesn't show up. I'm afraid these requirements may make the process actually harder than it currently is. What if there is no potential mentor available? This reminds of the Google Summer of Code... Regards Antoine. From rdmurray at bitdance.com Thu Dec 7 14:36:19 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Thu, 07 Dec 2017 14:36:19 -0500 Subject: [python-committers] Official python-dev docker images In-Reply-To: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> References: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> Message-ID: <20171207193619.D0B4F1310019@webabinitio.net> On Thu, 07 Dec 2017 13:00:31 -0500, Barry Warsaw wrote: > Brett and I want to promote this more widely within the Python > community as the ???official Python Docker image??? that projects can use > in their own testing environments, or base their own images on it. We > wanted to give you guys a heads up first to get your feedback, and > maybe thoughts on the best places to promote this, e.g. on the > python.org website or other places. Well, the place to get a python Docker image listed would be https://hub.docker.com/_/python/. That's the first google hit for python docker, and it already has a host of images available. How does yours differ from those? It sounds like it is by having multiple versions and tox so you can test your library/ap against multiple Python versions using a single container. That does sound useful :) But, be careful with names. "official Python Docker image" sounds like what one would use when one wants to *run* a python application in a docker container, which is what the images that are currently listed on the page mentioned above seem directed at. --David From brett at python.org Thu Dec 7 14:43:40 2017 From: brett at python.org (Brett Cannon) Date: Thu, 07 Dec 2017 19:43:40 +0000 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity In-Reply-To: References: Message-ID: On Wed, 6 Dec 2017 at 15:17 Victor Stinner wrote: > Hi, > > I wrote a quick & dirty parser to compute statistics on *new* CPython > core developer per year using the following page as data: > https://devguide.python.org/developers/ > > 2007: 15 > 2008: 19 > 2009: 11 > 2010: 20 > 2011: 12 > 2012: 9 > 2013: 4 > 2014: 10 > 2015: 2 > 2016: 5 > 2017: 2 > > Compare these numbers to St?phane Wirtel's statistics on pull requests: > https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests > > => Number of active core developerson on GitHub pull requests: 27 > (stats from February 2017 to October 2017) > (I'm not sure of the meaning of this number, it's the number of core > developer who authored pull requests, I don't think that it counts > core developers who only made reviews.) > > If you look at the size of the source code, it's still growing > constanly since 1990: > https://www.openhub.net/p/python/ > > 2007: around 783k lines > 2010: around 683k lines > 2013: around 800k lines > 2015: around 875k lines > 2017: around 973k lines > > The number of bugs is also constanly growing. Statistics on bugs since > 2011: > https://bugs.python.org/issue?@template=stats > > 2011: around 2500 open issues > 2013: around 4000 open issues > 2015: around 5000 open issues > 2017: around 6200 open issues > Do realize that open issues is a really misleading statistic as they include enhancement requests which we historically never close unless there's zero chance we will accept such a change. > > The size of the CPython project is constantly growing as its > complexity (technical debt? what is this? :-)), but the growth of core > developers is slowing down. > Well, you added code to speed up Unicode encoding/decoding, right? So it's just adding stuff to keep things performant as well as new things. It's just what happens when you're willing to improve things. > > I do consider that we need more people to handle the growing number of > issues and pull requests, so the question is now how to find and > "hire" (sorry, promote) them ;-) > > Maybe we have a problem with mentoring. Maybe the CPython code base > became too hard to train newcomers? Maybe we are too conservative? I > don't know. > I think it's partially a fact that Python's popularity has increased the pool size of contributors, so lots of people grabbing individual things. This leads to less of a chance to make sustained contributions. E.g. when I became a core dev it was because I was able to grab a new issue to work on that was easy at a very regular cadence, but I don't know if I could rectify that at this point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Dec 7 14:46:13 2017 From: brett at python.org (Brett Cannon) Date: Thu, 07 Dec 2017 19:46:13 +0000 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission In-Reply-To: <5A283657.60503@stoneleaf.us> References: <5A283657.60503@stoneleaf.us> Message-ID: On Wed, 6 Dec 2017 at 10:25 Ethan Furman wrote: > On 12/06/2017 09:43 AM, Victor Stinner wrote: > > > Congrats Cheryl! > > Possibly a dumb question, but is Cheryl on this list? > Nope, but that's because we have kept this list to only core devs and not people who have triage powers on the issue tracker. -Brett > > -- > ~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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Thu Dec 7 16:02:48 2017 From: nad at python.org (Ned Deily) Date: Thu, 7 Dec 2017 16:02:48 -0500 Subject: [python-committers] Promote Julien Palard as core developer In-Reply-To: References: Message-ID: <4B6C8A48-3DE9-48BD-9BA1-8B19D1F51BBC@python.org> On Dec 6, 2017, at 19:48, Victor Stinner wrote: > I propose to promote Julien Palard as a core developer. A big +2 from me. Julien has been extremely helpful over the past half year or so with multiple behind-the-scenes documentation build issues. As Victor notes, he is familiar with the doc infrastructure, processes, and the people who work on them. I've found him to be easy to work with and to display good judgement. I would be very happy to see Julien take on a more formal role with our documentation process and any other area that he would like to get involved with. -- Ned Deily nad at python.org -- [] From barry at python.org Thu Dec 7 16:28:39 2017 From: barry at python.org (Barry Warsaw) Date: Thu, 7 Dec 2017 16:28:39 -0500 Subject: [python-committers] Official python-dev docker images In-Reply-To: <20171207193619.D0B4F1310019@webabinitio.net> References: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> <20171207193619.D0B4F1310019@webabinitio.net> Message-ID: <932DCB02-E2F8-4BE4-83CF-7CFB25BE0D46@python.org> [Continuing to CC Abhilash, who is not on this list. -B] > On Dec 7, 2017, at 14:36, R. David Murray wrote: > > On Thu, 07 Dec 2017 13:00:31 -0500, Barry Warsaw wrote: >> Brett and I want to promote this more widely within the Python >> community as the ?official Python Docker image? that projects can use >> in their own testing environments, or base their own images on it. We >> wanted to give you guys a heads up first to get your feedback, and >> maybe thoughts on the best places to promote this, e.g. on the >> python.org website or other places. > > Well, the place to get a python Docker image listed would be > https://hub.docker.com/_/python/. That's the first google hit for python > docker, and it already has a host of images available. How does yours > differ from those? It sounds like it is by having multiple versions > and tox so you can test your library/ap against multiple Python > versions using a single container. That does sound useful :) There are several differences. Probably the two biggest are that 1) the ones on docker hub are not maintained by *us* but instead by ?the Docker Community?; 2) AFAICT, the ones on docker hub aren?t development focused images, so they only have one single version of Python installed. For any Python-based project that wants to e.g. run CI against multiple versions of Python, that isn?t helpful (and hence why we built this one). Our image is bigger, but more generally useful to library and application developers, rather than say, application deployment users. > But, be careful with names. "official Python Docker image" sounds like > what one would use when one wants to *run* a python application in a docker > container, which is what the images that are currently listed on the > page mentioned above seem directed at. That?s good feedback! I want to be clear about the purpose of this image, both in that it?s blessed and maintained by us, and that its focus is on the Python library and application developer (primarily for testing purposes). So maybe: Python.Org Official Multiversion Development Docker Image Doubleplus Good! :) Seriously, audience and naming are important to get right. -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 victor.stinner at gmail.com Thu Dec 7 17:20:29 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 7 Dec 2017 23:20:29 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: Message-ID: (I tried to answer to all replies. Since I chose to reply in a single email, so I chose to reply to own initial email.) Hi, It seems like I didn't express my ideas with the right words and so misguided the discussion. I'm sorry about that. I wrote a full "promotion process" document where I tried to pick better words. For example, I replaced "award" with "responsibility" ;-) My email: https://mail.python.org/pipermail/python-committers/2017-December/005000.html 2017-11-20 19:12 GMT+01:00 R. David Murray : >> Did it happen in the past that we removed the bug triage permission >> to someone who abused this power? > > Only once that I'm aware of. IMHO it's ok remove permissions if we have to. Instead of making such event abnormal, I proposed a training period of one month when the permission can be reverted anytime if the contributor misbehaves while being told to change their behaviour. I hope that the removal of the permission after the training period will be exceptional. I also added the need to get a mentor to reduce the risk even further. The mentor is not responsible of the behaviour of the contributor, but is here is guide and help the contributor. R. David Murray : >> Maybe we can give some guide lines on how to behave on the bug >> tracker? > > Enhance the bug triage section of the devguide, by all means :) To not forget, I created an issue in the devguide project! https://github.com/python/devguide/issues/308 2017-11-20 19:59 GMT+01:00 Ezio Melotti : > but we don't have a well defined procedure and sometimes people keep > contributing for weeks before someone realizes they could become > triagers. Aha. Maybe we need some tooling, like statistics on contributions to the bug tracker, just to detect earlier active "bug triagers"? On Git, it's simpler, there already many tools computing statistics on the number of commits. 2017-12-06 18:45 GMT+01:00 Ezio Melotti : > Depends on what you exactly mean with "award". Contributors might > want to be able to edit more fields on the tracker, and the triage bit > allows them to do it. This is beneficial for both the contributor and > the other triagers, since they have one more helping hand. (...) Here is where I failed the most to explain myself. If you consider that the long term goal is to train contributors to become core developers, bug triage is just one of the task and responsibility of a core developer. To exagerate, you cannot become a core developer if you don't know how to triage bugs properly. In my point of view, giving the bug triage permission is first a new responsibility, not a permission or an "award". The contributor becomes able to make bigger mistakes and so must be careful. The idea is to give permissions and responsibilities step by step to contributors, rather than giving them as once as the "core developer package". To come back to bug triage itself, obviously, the permission gives access to features not available to regular contributors, and so allows to better triage bugs. 2017-12-06 19:45 GMT+01:00 Ned Deily : > In general, I agree with David's and Ezio's comments, in particular > the idea that "bug triage" should not be an "award" nor a necessary > first step towards being a committer. I think the skills necessary to > be a good bug triager are not the same as being a good core developer. > While the skill sets and experience level needed can overlap, I think > we should consider the two roles as separate "career paths". In other > words, some people would do a fine job as triager without wanting to > be a core developer or contributing their own code patches, and that's > fine. I agree and like the idea of contributors who enjoy bug triage without wanting to contribute to the code. But technically, when I say "bug triage permission", I understand at least being able to close a bug. It would be annoying if a core developer doesn't get this permission and so would be unable to close a bug once a fix is pushed, no? 2017-12-06 20:37 GMT+01:00 Terry Reedy : > I agree. Database maintenance is a separate skill and interest from > the 3 skills of patch writing, reviewing, and merging. Committers > need to be able to maintain and ultimately close the issues they work > on, but need not engage in general tracker gardening. While I agree that core developers are not *required* to triage bugs, I consider that it's a responsibility shared by core developers to take care of the bug tracker. As I consider that core developers should review pull requests, not only produce pull requests, and that's one of the difference I see between a regular contributor and a core developer. Again, I wouldn't say that it's a hard requirements, more a best effort responsibility ;-) 2017-12-06 23:35 GMT+01:00 Antoine Pitrou : > I wonder: is this the right question to ask? There are contributors > who will never become core developers. It's not a failure. How many > of us actually hoped or expected to become a core developer when they > started contributing? My hope is that many contributors are potential core developers but were stuck somewhere, and failed to get the right documentation or mentor to unblock them. Being a core developer is expensive of term of time and energy, and too few people have time and energy for that. I am trying to increase our chances to get more candidates by making the path smoother and simpler, and by making the core developer sub-community a more warmly welcome place. 2017-12-06 23:35 GMT+01:00 Antoine Pitrou : > The real issue is not that the step is hard to climb, but that it is > hard to get people interested in climbing that step (and continue > being active afterwards, even though the step has been climbed). It > is to get people interested in the tasks and responsibilities > (sometimes annoyances) of being a core developer. In the "promotion process" documentation that I wrote, I now tried to insist on responsibilities over "additional permissions". Some people coming to me want to become a core developer without being aware of the disadvantages like the list of responsibilities. I am not sure that they have enough "free time" nor be ready to take these responsibilities. > Yes, so it's more a question of giving them the tools necessary to do > what they want to do. Not of giving them an award or a privilege :-) I'm not sure that I got your point. For example, for the bug tracker, do you mean that we should allow anyone to close bugs to let regular contributors triage bugs? 2017-12-07 0:39 GMT+01:00 Antoine Pitrou : > Therefore, we should strive to attract more contributors in the hope > that the number of core developers selected out of those contributors > will also increase. Over the last 9 months, St?phane Wirtel accounted 586 different contributors (who got pull requests merged). I'm not sure that we have a real issue with the number of contributors. 2017-12-07 4:36 GMT+01:00 Berker Peksa? : > Giving people an 'award' early may risk introducing unnecessary noise > on tracker. I understand that it's not end of the world, but note that > every wrong action needs to be reverted by another volunteer. I understand and agree with your point. There is a real risk of giving permissions without any kind of control. I adjusted my proposal by now requiring a mentor when someone gets the bug triage permission. Moreover, as I wrote previously, the permission will come with a training periof of 1 month when the permission can be reverted anytime if the contributor continue to mishave after having been told to change their behaviour. Would you feel more confortable with these two guards? A mentor and the ability to quickly revert the permission if needed. See my full "promotion process" for the details of the role of the mentor in that case. Victor From victor.stinner at gmail.com Thu Dec 7 17:20:55 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 7 Dec 2017 23:20:55 +0100 Subject: [python-committers] Cheryl Sabella was promoted to get bug triage permission In-Reply-To: References: Message-ID: 2017-12-06 18:43 GMT+01:00 Victor Stinner : > FYI She pushed not less than 14 commits into the master branch since > August, 2017. Oops, I used the wrong command to count her number of commits. vstinner at apu$ git log --author='Cheryl Sabella'|grep ^commit|wc -l 14 In fact, she changed her full name in her Git configuration in August, but not her email: vstinner at apu$ git log --author=cheryl.sabella at gmail.com|grep ^commit|wc -l 36 The correct number is that she got **36** commits merged into master since June 2017. Great! GitHub counts 52 commits, maybe it accounts also backports: https://github.com/python/cpython/graphs/contributors?from=2016-07-10&to=2017-12-07&type=c "csabella: 52 commits 7,647 ++ 4,601 --" I prefer to only count commits in master. Victor From victor.stinner at gmail.com Thu Dec 7 17:38:14 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 7 Dec 2017 23:38:14 +0100 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> References: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> Message-ID: 2017-12-07 19:21 GMT+01:00 Antoine Pitrou : >> == Step 2: Bug Triage Permission == >> >> Once a contributor becomes active enough, a core developer can propose >> to give the bug triage permission to the contributor. > > It sounds like you are not taking into account what was said by various > people during the previous discussion. I did, but I'm not sure that you (Antoine and others) understand properly my intent. Please see the reply that I just sent on the other "Requirements to get the "bug triage" permission?" thread. >> == Step 3: Getting a mentor == >> >> Python project is big and has a long history. Contributors need a >> referrer to guide them in this wild and dangerous (!) project, and in >> the development workflow. > > Perhaps you are overdoing this? :-) Maybe, who knows? :-) >> Required mentor skills: >> >> * Be a core contributor. >> * Be available at least during one whole month. >> * Follow the contributor: must get an update at least once a week, >> especially if the contributor doesn't show up. > > I'm afraid these requirements may make the process actually harder than > it currently is. What if there is no potential mentor available? This > reminds of the Google Summer of Code... I would lie if I would say that being a mentor is a trivial task that doesn't take any time. But from what I hear around me, mentoring the *key* difference to train faster motivated contributors. A single people cannot be the mentor of too many contributors at the same time. The bootstrap is going to be hard :-( Oh, if you didn't see it yet, I strongly suggest to watch Mariatta Wijaya's talk about mentoring at the last Pycon US: https://www.youtube.com/watch?v=Wc1krFb5ifQ She explained that mentoring is also valuable for the mentor! It goes in both directions. Another option is the idea proposed in parenthesis, that contributors mentor them each other. I wouldn't count as the official required mentoring, but it would help anyway. I think that it is already happening right now on the core-mentorship mailing list, helping each other. In the past, I mentored Xavier De Gaye and Xiang Zhang during one month *after* they became core developers. Honestly, it took me less than one hour per week. Ok, maybe they are not the best examples of contributors, since they already had a good background. But I'm not less afraid of being a mentor ;-) The "Step 3: Getting a mentor" isn't the first step just after "Step 0: Newcomers". The expectation is that the contributor already knows enough about Python workflow and code, before getting a mentor. For steps before the step 3, there is already the core-mentorship mailing list. IMHO this list is working well as intended. People who reply are kind, take time to explain, and contributors usually get a reply quickly. Bonus point: multiple core developers can be found there and actually answer, including Guido van Rossum! Mariatta got Guido van Rossum as a mentor (and also Raymond Hettinger if I understood correctly) and it was very successful, she became "quickly" a core developer and she is now involved in many parts of the Python development! (Sorry Mariatta to "use you" as an example!) I'm taking Mariatta as a concrete example of the success of mentoring. Victor From antoine at python.org Thu Dec 7 18:32:29 2017 From: antoine at python.org (Antoine Pitrou) Date: Fri, 8 Dec 2017 00:32:29 +0100 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: References: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> Message-ID: <4a1af446-c7f1-9675-9075-9ef73a4661c1@python.org> Le 07/12/2017 ? 23:38, Victor Stinner a ?crit?: > > Another option is the idea proposed in parenthesis, that contributors > mentor them each other. I wouldn't count as the official required > mentoring, but it would help anyway. I think that it is already > happening right now on the core-mentorship mailing list, helping each > other. Yes, well... core-mentorship has existed for years now (*), yet the number of promoted core developers has dwindled. I wouldn't count it as a success, at least not from that perspective (even though it may be a success from other perspectives) ;-) (*) it was created in 2011 AFAICT: https://mail.python.org/pipermail/python-dev/2011-March/110077.html Regards Antoine. From antoine at python.org Thu Dec 7 18:40:06 2017 From: antoine at python.org (Antoine Pitrou) Date: Fri, 8 Dec 2017 00:40:06 +0100 Subject: [python-committers] Number of contributors In-Reply-To: References: Message-ID: Le 07/12/2017 ? 23:20, Victor Stinner a ?crit?: > > 2017-12-07 0:39 GMT+01:00 Antoine Pitrou : >> Therefore, we should strive to attract more contributors in the hope >> that the number of core developers selected out of those contributors >> will also increase. > > Over the last 9 months, St?phane Wirtel accounted 586 different > contributors (who got pull requests merged). I'm not sure that we have a > real issue with the number of contributors. That number is not very interesting in itself, since Github indeed makes it easy to submit and integrate small fixes. So you can have many occasional contributors but very few regular contributors keen on tackling non-trivial tasks. It would be more interesting to know how many of those contributors submitted several (for example 5 or more) non-trivial fixes or improvements. Regards Antoine. From christian at python.org Thu Dec 7 19:00:16 2017 From: christian at python.org (Christian Heimes) Date: Fri, 8 Dec 2017 01:00:16 +0100 Subject: [python-committers] Official python-dev docker images In-Reply-To: <932DCB02-E2F8-4BE4-83CF-7CFB25BE0D46@python.org> References: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> <20171207193619.D0B4F1310019@webabinitio.net> <932DCB02-E2F8-4BE4-83CF-7CFB25BE0D46@python.org> Message-ID: <750f4695-27da-d1b0-7d09-0d277ef87629@python.org> On 2017-12-07 22:28, Barry Warsaw wrote: > That?s good feedback! I want to be clear about the purpose of this image, both in that it?s blessed and maintained by us, and that its focus is on the Python library and application developer (primarily for testing purposes). > > So maybe: Python.Org Official Multiversion Development Docker Image Doubleplus Good! Why is there 'Docker' in the name? Is the container image restricted to Docker runtime or can I use it with lxc, systemd-nspawn, rkt, or any other container runtime, too? There are likely legal issues with the name, too. After all 'Docker' is a registered trademark of Docker, Inc [1]. I'd be careful and call it 'Python.Org Official Multiversion Development Supercalifragilistic Container Image' instead. Christian [1] https://www.docker.com/brand-guidelines From christian at python.org Thu Dec 7 19:34:22 2017 From: christian at python.org (Christian Heimes) Date: Fri, 8 Dec 2017 01:34:22 +0100 Subject: [python-committers] Official python-dev docker images In-Reply-To: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> References: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> Message-ID: On 2017-12-07 19:00, Barry Warsaw wrote: > As part of the importlib_resources skunkworks project Brett and I have been working on (just announced), we?ve also put together a nice Docker image that we?re using for our automated testing. This image is based on Ubuntu 16.04 and provides the latest stable releases of Python 2.7, and 3.4-3.6, along with a mostly up-to-date git checkout of master, currently Python 3.7 of course. Once 3.7 is released to beta, we intend to track its release tarballs too. > > We also install a few other commonly needed tools, like pip, git, unzip, wget, mypy, and tox. > > Here?s the project repo: > > https://gitlab.com/python-devs/ci-images > > Huge shout out to Abhilash Raj who helped us clean up and compactify the image, and also for setting up automated publishing to quay.io. In case you weren?t aware, Abhilash is who I passed GNU Mailman project leadership to, so he has a lot of Python experience, and a ton of expertise in the image space. He?s an amazing amount of work to improve the quality of this image! > > Brett and I want to promote this more widely within the Python community as the ?official Python Docker image? that projects can use in their own testing environments, or base their own images on it. We wanted to give you guys a heads up first to get your feedback, and maybe thoughts on the best places to promote this, e.g. on the python.org website or other places. > > We welcome your participation too of course! I?m happy to give write access to the project to any Python committer who wants to help. Shiny! You'll get extra bonus points for not running as root. :) I'm curious, what is the reason of compiling CPython yourself? Ubuntu has the deadsnakes project. Fedora has packages for Python 3.3, 3.4, and 3.5. Could I convince you to put some builds of OpenSSL and LibreSSL into the container, too? Ubuntu 16.04 has only OpenSSL 1.0.2. A while ago I added a script to CPython that downloads, compiles and installs multiple versions in a shared directory (../multissl relative to cpython checkout). The script can be used to run the SSL test suites (ssl, asyncio, urllib, smtp, ...) against all installed versions. https://github.com/python/cpython/blob/master/Tools/ssl/multissltests.py Regards, Christian From willingc at gmail.com Thu Dec 7 20:31:51 2017 From: willingc at gmail.com (Carol Willing) Date: Thu, 7 Dec 2017 19:31:51 -0600 Subject: [python-committers] Promote Julien Palard as core developer In-Reply-To: <4B6C8A48-3DE9-48BD-9BA1-8B19D1F51BBC@python.org> References: <4B6C8A48-3DE9-48BD-9BA1-8B19D1F51BBC@python.org> Message-ID: Enthusiastic +1 from me. Great work on docs and localization. On Thu, Dec 7, 2017 at 3:02 PM, Ned Deily wrote: > On Dec 6, 2017, at 19:48, Victor Stinner wrote: > > I propose to promote Julien Palard as a core developer. > > A big +2 from me. Julien has been extremely helpful over the past half > year or so with multiple behind-the-scenes documentation build issues. As > Victor notes, he is familiar with the doc infrastructure, processes, and > the people who work on them. I've found him to be easy to work with and to > display good judgement. I would be very happy to see Julien take on a more > formal role with our documentation process and any other area that he would > like to get involved with. > > -- > 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/ > -- *Carol Willing* Research Software Engineer Project Jupyter at Cal Poly SLO cawillin at calpoly.edu *Signature strengths* *Empathy - Relator - Ideation - Strategic - Learner* -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Dec 7 22:14:14 2017 From: barry at python.org (Barry Warsaw) Date: Thu, 7 Dec 2017 22:14:14 -0500 Subject: [python-committers] Official python-dev docker images In-Reply-To: References: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> Message-ID: On Dec 7, 2017, at 19:34, Christian Heimes wrote: > > Shiny! You'll get extra bonus points for not running as root. :) Don?t forget, there?s a bug tracker you can submit requests to. > I'm curious, what is the reason of compiling CPython yourself? Ubuntu > has the deadsnakes project. Fedora has packages for Python 3.3, 3.4, and > 3.5. I really want clean builds of upstream tarball releases. Debian/Ubuntu for sure, and I would bet Fedora too, has downstream deltas applied, so if something fails there, how do you know it?s because of your package or something the distro added? Note that we do install the build dependencies for the Pythons so they?ll link against platform libraries and such. > Could I convince you to put some builds of OpenSSL and LibreSSL into the > container, too? You can totally file an issue so we can discuss it. :) https://gitlab.com/python-devs/ci-images/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 ezio.melotti at gmail.com Fri Dec 8 08:19:04 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 8 Dec 2017 14:19:04 +0100 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: References: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> Message-ID: On Thu, Dec 7, 2017 at 11:38 PM, Victor Stinner wrote: > 2017-12-07 19:21 GMT+01:00 Antoine Pitrou : >>> == Step 2: Bug Triage Permission == >>> >>> Once a contributor becomes active enough, a core developer can propose >>> to give the bug triage permission to the contributor. >> >> It sounds like you are not taking into account what was said by various >> people during the previous discussion. > > I did, but I'm not sure that you (Antoine and others) understand > properly my intent. > > Please see the reply that I just sent on the other "Requirements to > get the "bug triage" permission?" thread. > > >>> == Step 3: Getting a mentor == >>> >>> Python project is big and has a long history. Contributors need a >>> referrer to guide them in this wild and dangerous (!) project, and in >>> the development workflow. >> >> Perhaps you are overdoing this? :-) > > Maybe, who knows? :-) > > >>> Required mentor skills: >>> >>> * Be a core contributor. >>> * Be available at least during one whole month. >>> * Follow the contributor: must get an update at least once a week, >>> especially if the contributor doesn't show up. >> >> I'm afraid these requirements may make the process actually harder than >> it currently is. What if there is no potential mentor available? This >> reminds of the Google Summer of Code... > > I would lie if I would say that being a mentor is a trivial task that > doesn't take any time. But from what I hear around me, mentoring the > *key* difference to train faster motivated contributors. > In my experience, contributors that get promoted to core devs are usually already experienced, but they might not be familiar with all the quirks of CPython development and they will likely have a few CPython-specific questions. When I became a core dev I don't remember having an official mentor. I had several different questions (should I backport this to Python 2.3? how do I use svnmerge? how do I create a wide unicode debug build? which rst role should I use to document X?) and always received a timely reply from several different people, depending on who was available and their main area of expertise (also note that there was no devguide back then :). In my opinion, the role of the mentor should boil down to: 1) be a reference for the new core dev and be available in case everything else fails (e.g. if no one else answers a question); 2) be responsible for the mistakes the new core dev might make (e.g. help fixing up a bad merge or a broken buildbot caused by the new core dev). The mentor shouldn't babysit the new core dev and be in the only point of contact. The new core dev should: 1) interact with the other core devs and the community in general; 2) reach to the mentor only when necessary (i.e. no one else replied, something import/urgent/"personal"). For GSoC the situation is different: 1) GSoC students have to work on a specific project with specific goals, requirements, and deadlines; 2) GSoC students are usually less experience and need to be followed, guided, and sometimes pushed; 3) Given its breadth and maturity, CPython itself is not a particularly good candidate for GSoC projects. Best Regards, Ezio Melotti > A single people cannot be the mentor of too many contributors at the > same time. The bootstrap is going to be hard :-( > > > Oh, if you didn't see it yet, I strongly suggest to watch Mariatta > Wijaya's talk about mentoring at the last Pycon US: > https://www.youtube.com/watch?v=Wc1krFb5ifQ > > She explained that mentoring is also valuable for the mentor! It goes > in both directions. > > > Another option is the idea proposed in parenthesis, that contributors > mentor them each other. I wouldn't count as the official required > mentoring, but it would help anyway. I think that it is already > happening right now on the core-mentorship mailing list, helping each > other. > > > In the past, I mentored Xavier De Gaye and Xiang Zhang during one > month *after* they became core developers. Honestly, it took me less > than one hour per week. Ok, maybe they are not the best examples of > contributors, since they already had a good background. But I'm not > less afraid of being a mentor ;-) > > The "Step 3: Getting a mentor" isn't the first step just after "Step > 0: Newcomers". The expectation is that the contributor already knows > enough about Python workflow and code, before getting a mentor. > > For steps before the step 3, there is already the core-mentorship > mailing list. IMHO this list is working well as intended. People who > reply are kind, take time to explain, and contributors usually get a > reply quickly. Bonus point: multiple core developers can be found > there and actually answer, including Guido van Rossum! > > Mariatta got Guido van Rossum as a mentor (and also Raymond Hettinger > if I understood correctly) and it was very successful, she became > "quickly" a core developer and she is now involved in many parts of > the Python development! (Sorry Mariatta to "use you" as an example!) > I'm taking Mariatta as a concrete example of the success of mentoring. > > 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 victor.stinner at gmail.com Fri Dec 8 10:32:17 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Fri, 8 Dec 2017 16:32:17 +0100 Subject: [python-committers] Promote Julien Palard as core developer In-Reply-To: References: Message-ID: Wow, I didn't expect such warmly welcome for Julien Palard! I counted 6 positive votes (Nick, Zachary, Ethan, Mariatta, Ned, Carol), in addition to my implicit positive vote. I declare the vote done and wish welcome to our new core developer, Julien Palard! ? ? ? ? I will now follow https://devguide.python.org/coredev/#gaining-commit-privileges process for the practical part. Victor 2017-12-07 1:48 GMT+01:00 Victor Stinner : > Hi, > > I propose to promote Julien Palard as a core developer. > > Julien Palard is leading the french translation of the Python > documentation since 2 or 3 years. He spent a lot of time to try to get > this translation online. Since he was unlucky on the python-ideas > mailing list, I convinced him to write down a PEP. He wrote it with > Naoki INADA (who is translated the documentation to Japanese) and me. > It wasn't easy to write the PEP and get it approved: it took almost 1 > year and a half! The PEP 545 was approved and implemented in Python > 3.7! > > https://www.python.org/dev/peps/pep-0545/ > > Thanks to Julien (and others), translated documentations are now online at: > > https://docs.python.org/fr/ -- French > https://docs.python.org/ja/ -- Japanese > > See also the What's New in Python 3.7 entry: > https://docs.python.org/dev/whatsnew/3.7.html#documentation > > Julien spent a lot of time to fix a lot of various issues in the > documentation, the docsbuild-scripts project used to build the CPython > documentation, Sphinx, etc. to be able to translate properly the > documentation. > > For me, the documentation and the docsbuild-scripts project are > tightly coupled to the CPython project. Last june, I even asked to > give the commit bit to Julien on the > https://github.com/python/docsbuild-scripts/ project on this list, > since I expected that this project was part of CPython (it isn't, it's > another "team" on GitHub, if I understood correctly) :-) In the > meanwhile, Julien became a "core developer" on this project as well. > > He also worked closely with the Python infra team to fix a few bugs > when the translated documentation was published at python.org. > > To come back to CPython itself, Julien Palard already got 18 commits > merged into the master branch since January 2016: 11 before GitHub > ("patch by Julien Palard") + 7 since CPython migrated to GitHub > ("Julien Palard" author). Most of his commits are related to the > Python documentation content and tooling to build the documentation. > He fixed "bugs" in the documentation, to clarify some documentation. > > Giving him the commit bit would ease his work, since too few people > are looking at these areas of the code. When I reviewed his patches, > they are usually good after one or two iterations, and Julien welcomes > criticism. > > I know that Julien doesn't have the typical profile of core > developers, only or mostly contribute to the code: Julien is currently > focused on the doculmentation. But I believe (because he told me so > ;-)) that Julien will slowly contribute to other areas of the code, > once he will feel more confortable, and I may guide him in the code if > needed. I think that many of us started to contribute to a project on > its documentation ;-) > > I don't think that he needs an official menthor since he already knows > well the CPython workflow, and he knows how to ask questions if needed > ;-) > > Promoting Julien is part of my global idea/project of trying to > recognize more contributions which are not strictly code, but as > useful or even more useful than code! Python documentation is part of > Python's success. I was told many times that Python has a good > documentation, it's nice to hear that ! IMHO reducing CPython to its C > and Python code is wrong and nor fair, CPython made of much more > "sub-projects". > > Victor From victor.stinner at gmail.com Fri Dec 8 10:47:58 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Fri, 8 Dec 2017 16:47:58 +0100 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: 2017-12-06 17:57 GMT+01:00 Mariatta Wijaya : > Please add Ivan to the Developer Log in Dev Guide, and he should subscribe > to python-committers mailing list :) I added Ivan to the Devguide: https://github.com/python/devguide/commit/f414589365e8d3808eaef3cf9f2b7370314133a1 Victor From ezio.melotti at gmail.com Fri Dec 8 10:48:18 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 8 Dec 2017 16:48:18 +0100 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity In-Reply-To: References: Message-ID: On Thu, Dec 7, 2017 at 8:43 PM, Brett Cannon wrote: > > > On Wed, 6 Dec 2017 at 15:17 Victor Stinner wrote: >> >> Hi, >> >> I wrote a quick & dirty parser to compute statistics on *new* CPython >> core developer per year using the following page as data: >> https://devguide.python.org/developers/ >> >> 2007: 15 >> 2008: 19 >> 2009: 11 >> 2010: 20 >> 2011: 12 >> 2012: 9 >> 2013: 4 >> 2014: 10 >> 2015: 2 >> 2016: 5 >> 2017: 2 >> >> Compare these numbers to St?phane Wirtel's statistics on pull requests: >> https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests >> >> => Number of active core developerson on GitHub pull requests: 27 >> (stats from February 2017 to October 2017) >> (I'm not sure of the meaning of this number, it's the number of core >> developer who authored pull requests, I don't think that it counts >> core developers who only made reviews.) >> >> If you look at the size of the source code, it's still growing >> constanly since 1990: >> https://www.openhub.net/p/python/ >> >> 2007: around 783k lines >> 2010: around 683k lines >> 2013: around 800k lines >> 2015: around 875k lines >> 2017: around 973k lines >> >> The number of bugs is also constanly growing. Statistics on bugs since >> 2011: >> https://bugs.python.org/issue?@template=stats >> >> 2011: around 2500 open issues >> 2013: around 4000 open issues >> 2015: around 5000 open issues >> 2017: around 6200 open issues > > > Do realize that open issues is a really misleading statistic as they include > enhancement requests which we historically never close unless there's zero > chance we will accept such a change. > Here is a breakdown: 2443 behavior 2124 enhancements 224 crash 170 compile error 125 resource usage 104 performance 44 security >> >> >> The size of the CPython project is constantly growing as its >> complexity (technical debt? what is this? :-)), but the growth of core >> developers is slowing down. > > > Well, you added code to speed up Unicode encoding/decoding, right? So it's > just adding stuff to keep things performant as well as new things. It's just > what happens when you're willing to improve things. > >> >> >> I do consider that we need more people to handle the growing number of >> issues and pull requests, so the question is now how to find and >> "hire" (sorry, promote) them ;-) >> >> Maybe we have a problem with mentoring. Maybe the CPython code base >> became too hard to train newcomers? Maybe we are too conservative? I >> don't know. > > > I think it's partially a fact that Python's popularity has increased the > pool size of contributors, so lots of people grabbing individual things. > This leads to less of a chance to make sustained contributions. E.g. when I > became a core dev it was because I was able to grab a new issue to work on > that was easy at a very regular cadence, but I don't know if I could rectify > that at this point. > I think it also has to do with the maturity of the project. When I started I remember I wanted to fix some issue and when I ran the whole test suite I had at least a dozen failing on my machine, so I went and fix those as well. But to fix those I needed to add more stuff to test.support and to regrtest, and so I did. Then those changes needed to be documented, but the documentation was missing. So I started improving the documentation and even after all that was done there were still plenty of low hanging fruits on the bug tracker or other issues to work on. Then Python 3 came, and there was more work to be done. Nowadays the situation is much better, Python is more stable and mature, and what's left is more difficult, obscure, or controversial. There are still new modules and features being added and ISTM that most of the new core devs are working on those (e.g. asyncio/typing/etc), but otherwise finding new easy issues is becoming increasingly more difficult. Best Regards, Ezio Melotti From levkivskyi at gmail.com Fri Dec 8 10:49:30 2017 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Fri, 8 Dec 2017 16:49:30 +0100 Subject: [python-committers] Adding Ivan Levkivskyi as a core committer In-Reply-To: References: Message-ID: Thank you, Victor! -- Ivan On 8 December 2017 at 16:47, Victor Stinner wrote: > 2017-12-06 17:57 GMT+01:00 Mariatta Wijaya : > > Please add Ivan to the Developer Log in Dev Guide, and he should > subscribe > > to python-committers mailing list :) > > I added Ivan to the Devguide: > https://github.com/python/devguide/commit/f414589365e8d3808eaef3cf9f2b73 > 70314133a1 > > 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 victor.stinner at gmail.com Fri Dec 8 11:10:54 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Fri, 8 Dec 2017 17:10:54 +0100 Subject: [python-committers] Promote Julien Palard as core developer In-Reply-To: References: Message-ID: 2017-12-08 16:32 GMT+01:00 Victor Stinner : > I declare the vote done and wish welcome to our new core developer, > Julien Palard! ? ? ? ? I added Julien to the Devguide: https://github.com/python/devguide/commit/f414589365e8d3808eaef3cf9f2b7370314133a1 I will now see with him for the other steps (GitHub organization, subscribe to python-committers). Victor From ezio.melotti at gmail.com Fri Dec 8 11:19:17 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 8 Dec 2017 17:19:17 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: Message-ID: On Thu, Dec 7, 2017 at 11:20 PM, Victor Stinner wrote: > (I tried to answer to all replies. Since I chose to reply in a single > email, so I chose to reply to own initial email.) > > Hi, > > It seems like I didn't express my ideas with the right words and so > misguided the discussion. I'm sorry about that. I wrote a full > "promotion process" document where I tried to pick better words. For > example, I replaced "award" with "responsibility" ;-) > > My email: > https://mail.python.org/pipermail/python-committers/2017-December/005000.html > > 2017-11-20 19:12 GMT+01:00 R. David Murray : >>> Did it happen in the past that we removed the bug triage permission >>> to someone who abused this power? >> >> Only once that I'm aware of. > > IMHO it's ok remove permissions if we have to. Instead of making such > event abnormal, I proposed a training period of one month when the > permission can be reverted anytime if the contributor misbehaves while > being told to change their behaviour. > > I hope that the removal of the permission after the training period will > be exceptional. I also added the need to get a mentor to reduce the risk > even further. The mentor is not responsible of the behaviour of the > contributor, but is here is guide and help the contributor. > While most of these suggestions seem to help define the process, ISTM they are also making it more bureaucratic. > > R. David Murray : >>> Maybe we can give some guide lines on how to behave on the bug >>> tracker? >> >> Enhance the bug triage section of the devguide, by all means :) > > To not forget, I created an issue in the devguide project! > https://github.com/python/devguide/issues/308 > > > 2017-11-20 19:59 GMT+01:00 Ezio Melotti : >> but we don't have a well defined procedure and sometimes people keep >> contributing for weeks before someone realizes they could become >> triagers. > > Aha. Maybe we need some tooling, like statistics on contributions to the > bug tracker, just to detect earlier active "bug triagers"? > This can be done (e.g. the famous highscores page we have been talking about). > On Git, it's simpler, there already many tools computing statistics on > the number of commits. > > > 2017-12-06 18:45 GMT+01:00 Ezio Melotti : >> Depends on what you exactly mean with "award". Contributors might >> want to be able to edit more fields on the tracker, and the triage bit >> allows them to do it. This is beneficial for both the contributor and >> the other triagers, since they have one more helping hand. (...) > > Here is where I failed the most to explain myself. > > If you consider that the long term goal is to train contributors to > become core developers, bug triage is just one of the task and > responsibility of a core developer. To exagerate, you cannot become a > core developer if you don't know how to triage bugs properly. > > In my point of view, giving the bug triage permission is first a new > responsibility, not a permission or an "award". The contributor becomes > able to make bigger mistakes and so must be careful. The idea is to give > permissions and responsibilities step by step to contributors, rather > than giving them as once as the "core developer package". > With this I agree, and as I mentioned below, I think all core devs should have the triage bit and know how to use it. > To come back to bug triage itself, obviously, the permission gives > access to features not available to regular contributors, and so allows > to better triage bugs. > > > 2017-12-06 19:45 GMT+01:00 Ned Deily : >> In general, I agree with David's and Ezio's comments, in particular >> the idea that "bug triage" should not be an "award" nor a necessary >> first step towards being a committer. I think the skills necessary to >> be a good bug triager are not the same as being a good core developer. >> While the skill sets and experience level needed can overlap, I think >> we should consider the two roles as separate "career paths". In other >> words, some people would do a fine job as triager without wanting to >> be a core developer or contributing their own code patches, and that's >> fine. > > I agree and like the idea of contributors who enjoy bug triage without > wanting to contribute to the code. > > But technically, when I say "bug triage permission", I understand at > least being able to close a bug. It would be annoying if a core > developer doesn't get this permission and so would be unable to close a > bug once a fix is pushed, no? > All core devs should have the triage bit, even though many of them are only interested in using it for the issues they are working on. There are however other triagers that just go through the issues and adjust fields or comment, even if they have no intention of working on the issue itself. While it's technically true that there might be people that want to triage but not contribute code, most of them do contribute, and triage while going through the issues. > > 2017-12-06 20:37 GMT+01:00 Terry Reedy : >> I agree. Database maintenance is a separate skill and interest from >> the 3 skills of patch writing, reviewing, and merging. Committers >> need to be able to maintain and ultimately close the issues they work >> on, but need not engage in general tracker gardening. > > While I agree that core developers are not *required* to triage bugs, I > consider that it's a responsibility shared by core developers to take > care of the bug tracker. > > As I consider that core developers should review pull requests, not only > produce pull requests, and that's one of the difference I see between a > regular contributor and a core developer. Again, I wouldn't say that > it's a hard requirements, more a best effort responsibility ;-) > > > 2017-12-06 23:35 GMT+01:00 Antoine Pitrou : >> I wonder: is this the right question to ask? There are contributors >> who will never become core developers. It's not a failure. How many >> of us actually hoped or expected to become a core developer when they >> started contributing? > > My hope is that many contributors are potential core developers but were > stuck somewhere, and failed to get the right documentation or mentor to > unblock them. > This is a good point, but indeed, how many are contributing with the goal and hope of becoming core devs? How many are contributing because they like the project, and would be happy to become core devs? How many are just scratching a itch but otherwise have no desire to contribute to other aspects of the project? Finding an answer to these questions might help understanding where are the problems that need to be addressed. Best Regards, Ezio Melotti > Being a core developer is expensive of term of time and energy, and too > few people have time and energy for that. I am trying to increase our > chances to get more candidates by making the path smoother and simpler, > and by making the core developer sub-community a more warmly welcome > place. > > > 2017-12-06 23:35 GMT+01:00 Antoine Pitrou : >> The real issue is not that the step is hard to climb, but that it is >> hard to get people interested in climbing that step (and continue >> being active afterwards, even though the step has been climbed). It >> is to get people interested in the tasks and responsibilities >> (sometimes annoyances) of being a core developer. > > In the "promotion process" documentation that I wrote, I now tried to > insist on responsibilities over "additional permissions". Some people > coming to me want to become a core developer without being aware of the > disadvantages like the list of responsibilities. I am not sure that they > have enough "free time" nor be ready to take these responsibilities. > > >> Yes, so it's more a question of giving them the tools necessary to do >> what they want to do. Not of giving them an award or a privilege :-) > > I'm not sure that I got your point. For example, for the bug tracker, do > you mean that we should allow anyone to close bugs to let regular > contributors triage bugs? > > > 2017-12-07 0:39 GMT+01:00 Antoine Pitrou : >> Therefore, we should strive to attract more contributors in the hope >> that the number of core developers selected out of those contributors >> will also increase. > > Over the last 9 months, St?phane Wirtel accounted 586 different > contributors (who got pull requests merged). I'm not sure that we have a > real issue with the number of contributors. > > > 2017-12-07 4:36 GMT+01:00 Berker Peksa? : >> Giving people an 'award' early may risk introducing unnecessary noise >> on tracker. I understand that it's not end of the world, but note that >> every wrong action needs to be reverted by another volunteer. > > I understand and agree with your point. There is a real risk of giving > permissions without any kind of control. I adjusted my proposal by now > requiring a mentor when someone gets the bug triage permission. > > Moreover, as I wrote previously, the permission will come with a > training periof of 1 month when the permission can be reverted anytime > if the contributor continue to mishave after having been told to change > their behaviour. > > Would you feel more confortable with these two guards? A mentor and the > ability to quickly revert the permission if needed. > > See my full "promotion process" for the details of the role of the > mentor in that case. > > > 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 victor.stinner at gmail.com Fri Dec 8 11:20:03 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Fri, 8 Dec 2017 17:20:03 +0100 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: References: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> Message-ID: 2017-12-08 14:19 GMT+01:00 Ezio Melotti : > In my opinion, the role of the mentor should boil down to: > 1) be a reference for the new core dev and be available in case > everything else fails (e.g. if no one else answers a question); > 2) be responsible for the mistakes the new core dev might make (e.g. > help fixing up a bad merge or a broken buildbot caused by the new core > dev). > The mentor shouldn't babysit the new core dev and be in the only point > of contact. I can only agree with you on these points :-) > The new core dev should: > 1) interact with the other core devs and the community in general; > 2) reach to the mentor only when necessary (i.e. no one else replied, > something import/urgent/"personal"). Hum, maybe the process document should give a few pointers to the proper place to ask questions at each step? For example, core-mentorship before coming a core, and then maybe more on python-committers after becoming a core? Victor From victor.stinner at gmail.com Fri Dec 8 11:32:13 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Fri, 8 Dec 2017 17:32:13 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: Message-ID: 2017-12-08 17:19 GMT+01:00 Ezio Melotti : >> Aha. Maybe we need some tooling, like statistics on contributions to the >> bug tracker, just to detect earlier active "bug triagers"? >> > > This can be done (e.g. the famous highscores page we have been talking about). My opinion on such statistics is that they must not be public. I don't want to reward the highest number of contributions. As I wrote in the process documentation, what matters is the quality and kind of the contributions, and also the commitment. But a private tool, only accessible to core dev for example, would easy the work of identifying active contributors. > There are however other triagers that just go through the issues and > adjust fields or comment, even if they have no intention of working on > the issue itself. > While it's technically true that there might be people that want to > triage but not contribute code, most of them do contribute, and triage > while going through the issues. Hum, as Ned Deily wrote, some people don't want to become core developers and are fine to contribute as regular contributors. I should clarify this in the document. By the way, since the migration to Git and GitHub, contributing without being a core dev became simpler IMHO. >> My hope is that many contributors are potential core developers but were >> stuck somewhere, and failed to get the right documentation or mentor to >> unblock them. >> > > This is a good point, but indeed, how many are contributing with the > goal and hope of becoming core devs? How many are contributing > because they like the project, and would be happy to become core devs? > How many are just scratching a itch but otherwise have no desire to > contribute to other aspects of the project? > Finding an answer to these questions might help understanding where > are the problems that need to be addressed. Ow, these are tricky questions! Maybe a poll sent to contributors, or to python-dev, would help? Victor From vinay_sajip at yahoo.co.uk Fri Dec 8 11:33:19 2017 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Fri, 8 Dec 2017 16:33:19 +0000 (UTC) Subject: [python-committers] Licences for PyCharm and other JetBrains products References: <1420954884.1881529.1512750799609.ref@mail.yahoo.com> Message-ID: <1420954884.1881529.1512750799609@mail.yahoo.com> Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20. Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018. If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account. Regards, Vinay Sajip -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Fri Dec 8 11:44:55 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 8 Dec 2017 17:44:55 +0100 Subject: [python-committers] Requirements to get the "bug triage" permission? In-Reply-To: References: Message-ID: On Fri, Dec 8, 2017 at 5:32 PM, Victor Stinner wrote: > 2017-12-08 17:19 GMT+01:00 Ezio Melotti : >>> Aha. Maybe we need some tooling, like statistics on contributions to the >>> bug tracker, just to detect earlier active "bug triagers"? >>> >> >> This can be done (e.g. the famous highscores page we have been talking about). > > My opinion on such statistics is that they must not be public. I don't > want to reward the highest number of contributions. As I wrote in the > process documentation, what matters is the quality and kind of the > contributions, and also the commitment. > > But a private tool, only accessible to core dev for example, would > easy the work of identifying active contributors. > It doesn't necessarily have to be based solely on number of contribution. Twisted uses a formula that rewards different kind of contributions differently. In theory there could also be different leaderboards based on number of commits, lines of code, PR submitted, reviews done, PR/issues closed, etc. I trust that if we ever get around implementing this, the contributors won't abuse it, and to prevent that we can simply add a line saying something like "The number of contribution doesn't take into account the quality or the complexity of the contributions.". I don't think it should be private, as one of its main purposes is to recognize the work of the contributors, not only by us, but also by themselves and other contributors. > >> There are however other triagers that just go through the issues and >> adjust fields or comment, even if they have no intention of working on >> the issue itself. >> While it's technically true that there might be people that want to >> triage but not contribute code, most of them do contribute, and triage >> while going through the issues. > > Hum, as Ned Deily wrote, some people don't want to become core > developers and are fine to contribute as regular contributors. I > should clarify this in the document. > > By the way, since the migration to Git and GitHub, contributing > without being a core dev became simpler IMHO. > > >>> My hope is that many contributors are potential core developers but were >>> stuck somewhere, and failed to get the right documentation or mentor to >>> unblock them. >>> >> >> This is a good point, but indeed, how many are contributing with the >> goal and hope of becoming core devs? How many are contributing >> because they like the project, and would be happy to become core devs? >> How many are just scratching a itch but otherwise have no desire to >> contribute to other aspects of the project? >> Finding an answer to these questions might help understanding where >> are the problems that need to be addressed. > > Ow, these are tricky questions! Maybe a poll sent to contributors, or > to python-dev, would help? > > Victor From victor.stinner at gmail.com Fri Dec 8 11:49:16 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Fri, 8 Dec 2017 17:49:16 +0100 Subject: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity In-Reply-To: References: Message-ID: Ezio: > Nowadays the situation is much better, Python is more stable and > mature, and what's left is more difficult, obscure, or controversial. > There are still new modules and features being added and ISTM that > most of the new core devs are working on those (e.g. > asyncio/typing/etc), but otherwise finding new easy issues is becoming > increasingly more difficult. Hey, I really like your very positive view on CPython ;-) You made my day! Python is moving closer to perfection! "Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away" Victor From tjreedy at udel.edu Fri Dec 8 15:06:39 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 8 Dec 2017 15:06:39 -0500 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: References: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> Message-ID: On 12/8/2017 11:20 AM, Victor Stinner wrote: > 2017-12-08 14:19 GMT+01:00 Ezio Melotti : >> In my opinion, the role of the mentor should boil down to: >> 1) be a reference for the new core dev and be available in case >> everything else fails (e.g. if no one else answers a question); >> 2) be responsible for the mistakes the new core dev might make (e.g. >> help fixing up a bad merge or a broken buildbot caused by the new core >> dev). >> The mentor shouldn't babysit the new core dev and be in the only point >> of contact. > > I can only agree with you on these points :-) > >> The new core dev should: >> 1) interact with the other core devs and the community in general; >> 2) reach to the mentor only when necessary (i.e. no one else replied, >> something import/urgent/"personal"). > > Hum, maybe the process document should give a few pointers to the > proper place to ask questions at each step? For example, > core-mentorship before coming a core, and then maybe more on > python-committers after becoming a core? Committers should not ignore core-mentorship for general technical questions. Core-mentorship is where I finally got an answer on how to get tkinter working with a repository build -- from a non-coredev. At least one non-coredev contributed answers to my questions about using git. tjr From larry at hastings.org Fri Dec 8 17:10:45 2017 From: larry at hastings.org (Larry Hastings) Date: Fri, 8 Dec 2017 14:10:45 -0800 Subject: [python-committers] Proposed schedule for next 3.4 and 3.5 releases - end of January / early February Message-ID: Howdy howdy.? I know nobody's excited by the prospect of 3.4 and 3.5 releases--I mean, fer gosh sakes, neither of those versions even has f-strings! ? But we're about due.? I prefer to release roughly every six months, and the current releases came out in early August. Here's my proposed schedule: Sun Jan 21 2017 - release 3.4.8rc1 and 3.5.5rc1 Sun Feb 04 2017 - release 3.4.8 final and 3.5.5 final Unless I'm presented with good reasons to change it, that'll be the schedule.? I'll update the PEPs with the final release dates in about a week. Just for fun, I'll remind everybody here that 3.4 and 3.5 are both in security-fixes-only mode.? This means two things: 1. These will be source-code-only releases; the Python core dev team won't release any more binary installers for 3.4 or 3.5. 2. I'm the only person permitted to accept PRs for 3.4 and 3.5. If you have security fixes for either of those versions, please add me as a reviewer. Happy holidays to you and yours, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sat Dec 9 02:15:08 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 9 Dec 2017 17:15:08 +1000 Subject: [python-committers] Official python-dev docker images In-Reply-To: References: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> Message-ID: On 8 December 2017 at 13:14, Barry Warsaw wrote: > On Dec 7, 2017, at 19:34, Christian Heimes wrote: >> >> Shiny! You'll get extra bonus points for not running as root. :) > > Don?t forget, there?s a bug tracker you can submit requests to. > >> I'm curious, what is the reason of compiling CPython yourself? Ubuntu >> has the deadsnakes project. Fedora has packages for Python 3.3, 3.4, and >> 3.5. > > I really want clean builds of upstream tarball releases. Debian/Ubuntu for sure, and I would bet Fedora too, has downstream deltas applied, so if something fails there, how do you know it?s because of your package or something the distro added? Yeah, I'd advise the same: the CPython compatibility testing images should provide unpatched builds. That way, checking against the upstream builds becomes a first step in triage for problems encountered with redistributor builds: if a problem only shows up in the distro version, then distro specific patches would be the first place to look. Cheers, Nick. P.S. This thread would probably be better located on python-dev :) -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Sat Dec 9 02:41:17 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 9 Dec 2017 17:41:17 +1000 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> References: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> Message-ID: On 8 December 2017 at 04:21, Antoine Pitrou wrote: > > Le 07/12/2017 ? 19:01, Victor Stinner a ?crit : >> >> IMHO the current blocker issue is that it is too hard to become a core >> developer. > > I don't think so. It should not be harder than it was in 2010, yet we > are promoting way less core developers than we did. See previous > discussion. I'll note that one thing that *has* changed since then is that we've been putting a lot more emphasis on software distribution via PyPI. Part of that is the Python 2.7 feature freeze (so if you've wanted to deliver new functionality to Python 2 users, you've *had* to use PyPI, even if you're already a core developer), part of it has been improved tooling and other enhancements (pip was first released in 2011, and first bundled with CPython in early 2014), and part of it has simply been recognition that CPython rollout cycles through the full redistributor network are inherently slow (even 7 years after its initial release, Python *2.7* is at less than 100% penetration, with some infrastructure projects only just beginning to drop Python 2.6 support now). So while better enabling folks to bypass us entirely may seem like a weird thing to celebrate, I think it actually is worth celebrating, since it takes both us and our redistributors out of the critical path for the evolution of the Python ecosystem as a whole - we can serve more as popularisers of concepts & techniques initially defined elsewhere, rather than having to drive that exploration of the available design space ourselves. I think we've also had a lot of success in bringing the developer experience for core devs and non-core-devs closer together - while *technically* we can push directly to the main repository, very few of us actually do so. Even when we end up self-reviewing a change, we'll still typically run it through the PR process so Travis et al get a chance to run their pre-merge checks. Changing from "I need someone else to push the merge button for me" to "I push the merge button" is now more a difference in level of responsibility than it is a marked change in the contribution experience. That said, I'm still happy that Victor is taking the initiative to investigate our processes here, and look to make things a bit more objectively data-driven - when volunteers are mentoring and managing other volunteers, it's even easier for unconscious biases to come into play than it is in a more explicitly professional setting. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From antoine at python.org Sat Dec 9 05:55:50 2017 From: antoine at python.org (Antoine Pitrou) Date: Sat, 9 Dec 2017 11:55:50 +0100 Subject: [python-committers] RFC: Process to become a core developer In-Reply-To: References: <97f20d55-db8e-1e39-a001-2dbb0b788ae6@python.org> Message-ID: Le 09/12/2017 ? 08:41, Nick Coghlan a ?crit?: > On 8 December 2017 at 04:21, Antoine Pitrou wrote: >> >> Le 07/12/2017 ? 19:01, Victor Stinner a ?crit : >>> >>> IMHO the current blocker issue is that it is too hard to become a core >>> developer. >> >> I don't think so. It should not be harder than it was in 2010, yet we >> are promoting way less core developers than we did. See previous >> discussion. > > I'll note that one thing that *has* changed since then is that we've > been putting a lot more emphasis on software distribution via PyPI. This is sounding a bit like any piece of useful functionality would have been put in the stdlib before 2.7, but that is generally false. Twisted, Numpy, the various Web servers and frameworks out there have never been seriously considered for inclusion AFAIR. There always has been a health ecosystem of third-party libraries that existed happily alongside the main Python distribution. Conversely, there are some kinds of features that have a much more natural place in the standard distribution rather than third-party libraries. For example object serialization (pickle is a standard, if you have to complement / work around it through third-party hacks it weakens the whole ecosystem) or interfaces to low-level OS functionality (do you want to pip-install sendmsg() or sendfile()?). > I think we've also had a lot of success in bringing the developer > experience for core devs and non-core-devs closer together - while > *technically* we can push directly to the main repository, very few of > us actually do so. True. But that doesn't change the underlying issue. Core developers are required to actively review and vet proposed changes, and even to maintain important pieces of the stdlib. Regards Antoine. From victor.stinner at gmail.com Sat Dec 9 08:12:52 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Sat, 9 Dec 2017 14:12:52 +0100 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) Message-ID: Hi, For your information, I just sent emails to Julien, Cheryl and Sanyam to notify them that I will their mentor during one month. I asked them to ask me to double check before merging a pull request (Julien) or closing a bug (Cheryl and Sanyam). Since I'm trying for formalize the whole process to become a core dev, I kept a copy of my emails to serve as template for future mentors: https://github.com/vstinner/misc/blob/master/cpython/mentor_core_dev_email.rst https://github.com/vstinner/misc/blob/master/cpython/mentor_bug_triage_email.rst By the way, I'm now working on the "Process to become a core developer" document (maybe becoming a PEP later?) at: https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.rst (I almost didn't change since I sent it to python-committers) Victor From brett at python.org Sat Dec 9 12:58:39 2017 From: brett at python.org (Brett Cannon) Date: Sat, 09 Dec 2017 17:58:39 +0000 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: References: Message-ID: I have a subscription request to python-committers from Cheryl. Im planing rejecting it since we have kept this list only to committees, but I didn't want it to come off as rude when it happens. I also don't know if we want a triage-only list. On Sat, Dec 9, 2017, 05:13 Victor Stinner, wrote: > Hi, > > For your information, I just sent emails to Julien, Cheryl and Sanyam > to notify them that I will their mentor during one month. > > I asked them to ask me to double check before merging a pull request > (Julien) or closing a bug (Cheryl and Sanyam). > > Since I'm trying for formalize the whole process to become a core dev, > I kept a copy of my emails to serve as template for future mentors: > > > https://github.com/vstinner/misc/blob/master/cpython/mentor_core_dev_email.rst > > https://github.com/vstinner/misc/blob/master/cpython/mentor_bug_triage_email.rst > > By the way, I'm now working on the "Process to become a core > developer" document (maybe becoming a PEP later?) at: > > https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.rst > (I almost didn't change since I sent it to python-committers) > > 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 willingc at gmail.com Sat Dec 9 13:23:42 2017 From: willingc at gmail.com (Carol Willing) Date: Sat, 9 Dec 2017 12:23:42 -0600 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: References: Message-ID: > On Dec 9, 2017, at 11:58 AM, Brett Cannon wrote: > > I have a subscription request to python-committers from Cheryl. Im planing rejecting it since we have kept this list only to committees, but I didn't want it to come off as rude when it happens. > > I also don't know if we want a triage-only list. > Perhaps it would be a good idea to have a "core mentorship - triage" list which core devs interested in mentoring and triage can help answer questions from Cheryl and Sanyam and others down the road. Nice things about a list like this is it could be low traffic and supportive while helping to build maintainer skills over time. I would be happy to moderate and encourage folks on a list like that. > > On Sat, Dec 9, 2017, 05:13 Victor Stinner, > wrote: > Hi, > > For your information, I just sent emails to Julien, Cheryl and Sanyam > to notify them that I will their mentor during one month. > > I asked them to ask me to double check before merging a pull request > (Julien) or closing a bug (Cheryl and Sanyam). > > Since I'm trying for formalize the whole process to become a core dev, > I kept a copy of my emails to serve as template for future mentors: > > https://github.com/vstinner/misc/blob/master/cpython/mentor_core_dev_email.rst > https://github.com/vstinner/misc/blob/master/cpython/mentor_bug_triage_email.rst > > By the way, I'm now working on the "Process to become a core > developer" document (maybe becoming a PEP later?) at: > https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.rst > (I almost didn't change since I sent it to python-committers) > > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Sat Dec 9 13:36:50 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Sat, 9 Dec 2017 10:36:50 -0800 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: References: Message-ID: I think questions about triaging can be asked in the regular core-mentorship as those are useful for all contributors and core devs. On Dec 9, 2017 10:23 AM, "Carol Willing" wrote: > > > On Dec 9, 2017, at 11:58 AM, Brett Cannon wrote: > > I have a subscription request to python-committers from Cheryl. Im planing > rejecting it since we have kept this list only to committees, but I didn't > want it to come off as rude when it happens. > > I also don't know if we want a triage-only list. > > > Perhaps it would be a good idea to have a "core mentorship - triage" list > which core devs interested in mentoring and triage can help answer > questions from Cheryl and Sanyam and others down the road. Nice things > about a list like this is it could be low traffic and supportive while > helping to build maintainer skills over time. I would be happy to moderate > and encourage folks on a list like that. > > > On Sat, Dec 9, 2017, 05:13 Victor Stinner, > wrote: > >> Hi, >> >> For your information, I just sent emails to Julien, Cheryl and Sanyam >> to notify them that I will their mentor during one month. >> >> I asked them to ask me to double check before merging a pull request >> (Julien) or closing a bug (Cheryl and Sanyam). >> >> Since I'm trying for formalize the whole process to become a core dev, >> I kept a copy of my emails to serve as template for future mentors: >> >> https://github.com/vstinner/misc/blob/master/cpython/ >> mentor_core_dev_email.rst >> https://github.com/vstinner/misc/blob/master/cpython/ >> mentor_bug_triage_email.rst >> >> By the way, I'm now working on the "Process to become a core >> developer" document (maybe becoming a PEP later?) at: >> https://github.com/vstinner/misc/blob/master/cpython/pep- >> core_dev_process.rst >> (I almost didn't change since I sent it to python-committers) >> >> 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/ > > > > _______________________________________________ > 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 victor.stinner at gmail.com Sat Dec 9 16:01:05 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Sat, 9 Dec 2017 22:01:05 +0100 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: References: Message-ID: I agree with Mariatta, I don't think that yet another mailing list is needed ;-) Brett: it's ok reject Cherl's subscription, maybe it's just a misunderstanding. I added Cheryl in CC to my email to python-commiters when I announced that she got the bug triage permission. Maybe such email should be sent to the core-mentorship mailing instead to be more consistent? Victor Le 9 d?c. 2017 19:37, "Mariatta Wijaya" a ?crit : > I think questions about triaging can be asked in the regular > core-mentorship as those are useful for all contributors and core devs. > > On Dec 9, 2017 10:23 AM, "Carol Willing" wrote: > >> >> >> On Dec 9, 2017, at 11:58 AM, Brett Cannon wrote: >> >> I have a subscription request to python-committers from Cheryl. Im >> planing rejecting it since we have kept this list only to committees, but I >> didn't want it to come off as rude when it happens. >> >> I also don't know if we want a triage-only list. >> >> >> Perhaps it would be a good idea to have a "core mentorship - triage" list >> which core devs interested in mentoring and triage can help answer >> questions from Cheryl and Sanyam and others down the road. Nice things >> about a list like this is it could be low traffic and supportive while >> helping to build maintainer skills over time. I would be happy to moderate >> and encourage folks on a list like that. >> >> >> On Sat, Dec 9, 2017, 05:13 Victor Stinner, >> wrote: >> >>> Hi, >>> >>> For your information, I just sent emails to Julien, Cheryl and Sanyam >>> to notify them that I will their mentor during one month. >>> >>> I asked them to ask me to double check before merging a pull request >>> (Julien) or closing a bug (Cheryl and Sanyam). >>> >>> Since I'm trying for formalize the whole process to become a core dev, >>> I kept a copy of my emails to serve as template for future mentors: >>> >>> https://github.com/vstinner/misc/blob/master/cpython/mentor_ >>> core_dev_email.rst >>> https://github.com/vstinner/misc/blob/master/cpython/mentor_ >>> bug_triage_email.rst >>> >>> By the way, I'm now working on the "Process to become a core >>> developer" document (maybe becoming a PEP later?) at: >>> https://github.com/vstinner/misc/blob/master/cpython/pep-cor >>> e_dev_process.rst >>> (I almost didn't change since I sent it to python-committers) >>> >>> 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/ >> >> >> >> _______________________________________________ >> 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/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at gmail.com Sat Dec 9 16:02:40 2017 From: willingc at gmail.com (Carol Willing) Date: Sat, 9 Dec 2017 15:02:40 -0600 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: References: Message-ID: <96E12EC8-C7D6-4C44-9CC8-B4F4EBB9E859@gmail.com> > On Dec 9, 2017, at 3:01 PM, Victor Stinner wrote: > > I agree with Mariatta, I don't think that yet another mailing list is needed ;-) > :-) > Brett: it's ok reject Cherl's subscription, maybe it's just a misunderstanding. I added Cheryl in CC to my email to python-commiters when I announced that she got the bug triage permission. Maybe such email should be sent to the core-mentorship mailing instead to be more consistent? That's a good idea to announce on core-mentorship going forward. > > Victor > > Le 9 d?c. 2017 19:37, "Mariatta Wijaya" > a ?crit : > I think questions about triaging can be asked in the regular core-mentorship as those are useful for all contributors and core devs. > > On Dec 9, 2017 10:23 AM, "Carol Willing" > wrote: > > >> On Dec 9, 2017, at 11:58 AM, Brett Cannon > wrote: >> >> I have a subscription request to python-committers from Cheryl. Im planing rejecting it since we have kept this list only to committees, but I didn't want it to come off as rude when it happens. >> >> I also don't know if we want a triage-only list. >> > > Perhaps it would be a good idea to have a "core mentorship - triage" list which core devs interested in mentoring and triage can help answer questions from Cheryl and Sanyam and others down the road. Nice things about a list like this is it could be low traffic and supportive while helping to build maintainer skills over time. I would be happy to moderate and encourage folks on a list like that. > >> >> On Sat, Dec 9, 2017, 05:13 Victor Stinner, > wrote: >> Hi, >> >> For your information, I just sent emails to Julien, Cheryl and Sanyam >> to notify them that I will their mentor during one month. >> >> I asked them to ask me to double check before merging a pull request >> (Julien) or closing a bug (Cheryl and Sanyam). >> >> Since I'm trying for formalize the whole process to become a core dev, >> I kept a copy of my emails to serve as template for future mentors: >> >> https://github.com/vstinner/misc/blob/master/cpython/mentor_core_dev_email.rst >> https://github.com/vstinner/misc/blob/master/cpython/mentor_bug_triage_email.rst >> >> By the way, I'm now working on the "Process to become a core >> developer" document (maybe becoming a PEP later?) at: >> https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.rst >> (I almost didn't change since I sent it to python-committers) >> >> 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/ > > > _______________________________________________ > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at palard.fr Sat Dec 9 15:56:10 2017 From: julien at palard.fr (Julien Palard) Date: Sat, 09 Dec 2017 15:56:10 -0500 Subject: [python-committers] Saying hello as a new core dev Message-ID: Hi, python-committers! That's huge, for me, to receive this notification "Your now a core developer, congratulations!" thanks everyone here! And waw, your messages in your votes to bring me in are heartwarming, as I said yesterday they validate, again and again, the ancient adage "Come for the language, stay for the community". ?--? Julien Palard https://mdk.fr From rdmurray at bitdance.com Sat Dec 9 18:46:32 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Sat, 09 Dec 2017 18:46:32 -0500 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: References: Message-ID: <20171209234632.730211310022@webabinitio.net> On Sat, 09 Dec 2017 14:12:52 +0100, Victor Stinner wrote: > I asked them to ask me to double check before merging a pull request > (Julien) or closing a bug (Cheryl and Sanyam). When I have promoted people to triage in the past I have not had them check with me before making changes, but instead simply encouraged them to ask me questions if they had doubts. I base this on the advice I was given my Martin von Loewis when he gave me triage privileges however many years ago it was. He said (paraphrased) "Don't be afraid to use this power. It is worse to to be tentative and not do the work than it is to do the work and make mistakes. All tracker changes are reversible, so don't be afraid to make changes." The point is, in Martin's judgement (and I have had no reason to doubt it in the years that have followed) is that it is a far more common problem for newly promoted people to be afraid to screw up than it is for someone to go rogue and not listen when communicated with. In my experience the latter has happened only once, and we have a lot of people with triage privileges. --David From ncoghlan at gmail.com Sat Dec 9 20:41:58 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 10 Dec 2017 11:41:58 +1000 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: <20171209234632.730211310022@webabinitio.net> References: <20171209234632.730211310022@webabinitio.net> Message-ID: On 10 December 2017 at 09:46, R. David Murray wrote: > The point is, in Martin's judgement (and I have had no reason to doubt > it in the years that have followed) is that it is a far more common > problem for newly promoted people to be afraid to screw up than it is > for someone to go rogue and not listen when communicated with. In my > experience the latter has happened only once, and we have a lot of > people with triage privileges. +1 - "Who am I to have this power?" is a pretty common reaction to community promotions, so erring on the side of "I trust your judgement, so you should trust your judgement" is a good way to go. But at the same time, we should make it clear that "Help me better calibrate my judgement" is an entirely appropriate use case for the core-mentorship list (and we keep those archives closed so they're not available to search engines). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From p.f.moore at gmail.com Sun Dec 10 07:18:30 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 10 Dec 2017 12:18:30 +0000 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: References: <20171209234632.730211310022@webabinitio.net> Message-ID: On 10 December 2017 at 01:41, Nick Coghlan wrote: > On 10 December 2017 at 09:46, R. David Murray wrote: >> The point is, in Martin's judgement (and I have had no reason to doubt >> it in the years that have followed) is that it is a far more common >> problem for newly promoted people to be afraid to screw up than it is >> for someone to go rogue and not listen when communicated with. In my >> experience the latter has happened only once, and we have a lot of >> people with triage privileges. > > +1 - "Who am I to have this power?" is a pretty common reaction to > community promotions, so erring on the side of "I trust your > judgement, so you should trust your judgement" is a good way to go. I absolutely agree with this view. Giving commit rights is (in my opinion) far more about saying that we trust someone's judgement than it is about giving out a privilege. And yet, certainly in my case, and in my experience in most other people's cases, being *told* that people trust your judgement doesn't eradicate that feeling that maybe they made a mistake... So making it clear to people they don't need to ask, but we're here to support them if they want to ask, is the right tone to take. > But at the same time, we should make it clear that "Help me better > calibrate my judgement" is an entirely appropriate use case for the > core-mentorship list (and we keep those archives closed so they're not > available to search engines). Definitely. Knowing where to go for advice, whether it's to help in difficult edge cases, or just for validation when you think you know the right answer but want to check, is the key thing for anyone new to the process (and honestly, for the old hands too). Paul From barry at python.org Sun Dec 10 18:28:37 2017 From: barry at python.org (Barry Warsaw) Date: Sun, 10 Dec 2017 18:28:37 -0500 Subject: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug) In-Reply-To: References: <20171209234632.730211310022@webabinitio.net> Message-ID: <038A5918-77C7-44FA-9130-C8C19CD48976@python.org> On Dec 9, 2017, at 20:41, Nick Coghlan wrote: > > +1 - "Who am I to have this power?" is a pretty common reaction to > community promotions, so erring on the side of "I trust your > judgement, so you should trust your judgement" is a good way to go. > > But at the same time, we should make it clear that "Help me better > calibrate my judgement" is an entirely appropriate use case for the > core-mentorship list (and we keep those archives closed so they're not > available to search engines). Very well said, Nick. It?s useful to remind new contributors that very few things are irreversible, and that there are lots of outlets for asking questions. -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 barry at python.org Sun Dec 10 18:51:01 2017 From: barry at python.org (Barry Warsaw) Date: Sun, 10 Dec 2017 18:51:01 -0500 Subject: [python-committers] Official python-dev docker images In-Reply-To: <750f4695-27da-d1b0-7d09-0d277ef87629@python.org> References: <678CA279-6034-470D-AB0C-BBC8BB000F0F@python.org> <20171207193619.D0B4F1310019@webabinitio.net> <932DCB02-E2F8-4BE4-83CF-7CFB25BE0D46@python.org> <750f4695-27da-d1b0-7d09-0d277ef87629@python.org> Message-ID: <560DED6C-4CA3-4C60-8C2A-9A2CC4FFBA03@python.org> On Dec 7, 2017, at 19:00, Christian Heimes wrote: > > Why is there 'Docker' in the name? Is the container image restricted to > Docker runtime or can I use it with lxc, systemd-nspawn, rkt, or any > other container runtime, too? I honestly don?t know, and I?ve only used it with Docker, but there is the Open Container Initiative to promote standards, so maybe it can. https://www.opencontainers.org/about > There are likely legal issues with the name, too. After all 'Docker' is > a registered trademark of Docker, Inc [1]. I'd be careful and call it > 'Python.Org Official Multiversion Development Supercalifragilistic > Container Image' instead. Yeah, that?s a good suggestion. Well, maybe without the Potential Poppins Infringement. (And yes, I?m going to follow up on python-dev now.) -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 victor.stinner at gmail.com Mon Dec 11 04:58:20 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 11 Dec 2017 10:58:20 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email Message-ID: Hi, On 12 February 2017, I got an email from Bitbucket: "we detected a suspicious login to your Bitbucket Cloud account. We believe that a malicious actor used a large database of usernames and passwords stolen from third party services to access Bitbucket Cloud accounts. We can't know exactly how your password was first compromised, however it was not caused by Atlassian." Wow. That's huge for me: * I was using the same password for almost all services (except of Gmail): GitHub, Bitbucket, a lot of web services. In term of security, that's "bad". I know... but it is convenient... * I had a few different password that I stored in clear text in a text file which was hosted on a private repository on... Bitbucket While *now* I'm quite sure that the hacker only succeed to log in but didn't notice my password file, it was a good "opportunity" to upgrade my security... By the way, I suggest you to subscribe to https://haveibeenpwned.com/ which is a service to be notified if one of the service that you are using have seen "pwned". Using victor.stinner at gmail.com you can see "Breaches you were pwned in: Dailymotion (october 2016) and GeekedIn (August 2016)". (There is also a pastebin with my email, but it's just statistics on Mercurial, nothing sensitive :-)) The question is no more if you have been hacked, but how much time do you have before one of the services that you are using will be hacked... haveibeenpwned.com only reference a few breaches that has been made public... It was an electric shock for me. I immediately changed the password of the most critical services for me: GitHub, Bitbucket and many others. I generated a random password of +10 characters (using KeePassX). I started to use KeePassX password manager to stop storing passwords in clear text, with a master passphrase to encrypt all these passwords. I also acquired a Yubikey Nano. It's 50$. You may think that it's expensive. But the question is more how much do you estimate all your data of all your computers? Less than 50$, seriously? :-) The next step was to enable 2-factor authentication on GitHub and Bitbucket: * Configure the yubikey to generate an OTP for GitHub (for "long press" on the key) * Firefox: install https://addons.mozilla.org/fr/firefox/addon/u2f-support-add-on/ to use Yubikey with GitHub (sadly, the plugin doesn't work with Bitbucket nor Google yet) * Enable 2-factor auth on GitHub and Bitbucket using Yubikey * Print two-step recoverty codes on paper and keep it safe somewhere If you cannot affort a Yubikey, don't or cannot use it, you may want to use FreeOTP: free OTP application for a smartphone (I'm using it on Android), usable with GitHub, Bitbucket, Google, etc. It's not exclusive, you can have multiple 2-factor keys (Yubikey, FreeOTP, something else). Oh, my explanation makes the assumption that you all already enabled 2-factor auth on your email, right? :-) If you wasn't aware: email is simply the *most* critical part of your whole online data. If a hacker gets access to your email, you already lost all your online accounts... For Gmail users: you may have a look at https://myaccount.google.com/security as well. Maybe remove old services that have access to your Google account? After the hack, I also generated a new SSH key, even if it wasn't stored online and is encrypted by a passphrase. Just because I was using the same key since many years. I chose to use the new modern ed25519 key format. It uses an elliptic curve rather than RSA, it's a different kind of security. While I don't know if it's more secure, I read that it's faster :-) https://en.wikipedia.org/wiki/EdDSA I was able to use this new key formats on all services... except Launchpad. Changing a private SSH key isn't easy: * You have to install the new SSH on most services that you are using * You have to manually remove the old SSH key from *all* services that you are using (there is no global "SSH revokation" service...) * I used ~/.ssh/known_hosts to get most services, but also updated GitHub, Bitbucket, etc. * There are a few other services like psf-salt/psf-chef where you may also want to see your SSH key updated * The question is then if the old SSH key must be removed... the problem is that I never tried to keep track of services that I'm using through SSH, so I decided to keep the old SSH key (outside ~/.ssh). In practice, I'm only using my new SSH private since longer than 6 months and I was never blocked. I also had trouble to get working SSH agent on Gnome for my ed25519 key, but I succeeded to enable the regular ssh-agent using systemd --user. Tell me if you want instructions for this part as well. Victor From antoine at python.org Mon Dec 11 05:07:08 2017 From: antoine at python.org (Antoine Pitrou) Date: Mon, 11 Dec 2017 11:07:08 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: <2d30f8e7-625d-7e94-2849-a44b70ad56c4@python.org> Le 11/12/2017 ? 10:58, Victor Stinner a ?crit?: > > I also had trouble to get working SSH agent on Gnome for my ed25519 > key, but I succeeded to enable the regular ssh-agent using systemd > --user. Tell me if you want instructions for this part as well. Blame gnome-keyring for this: https://bugzilla.gnome.org/show_bug.cgi?id=723274 Regards Antoine. From kushaldas at gmail.com Mon Dec 11 05:16:23 2017 From: kushaldas at gmail.com (Kushal Das) Date: Mon, 11 Dec 2017 15:46:23 +0530 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: On Mon, Dec 11, 2017 at 3:28 PM, Victor Stinner wrote: > Hi, > > > The next step was to enable 2-factor authentication on GitHub and Bitbucket: > > * Configure the yubikey to generate an OTP for GitHub (for "long > press" on the key) > * Firefox: install > https://addons.mozilla.org/fr/firefox/addon/u2f-support-add-on/ to use > Yubikey with GitHub (sadly, the plugin doesn't work with Bitbucket nor > Google yet) > * Enable 2-factor auth on GitHub and Bitbucket using Yubikey > * Print two-step recoverty codes on paper and keep it safe somewhere > > If you cannot affort a Yubikey, don't or cannot use it, you may want > to use FreeOTP: free OTP application for a smartphone (I'm using it on > Android), usable with GitHub, Bitbucket, Google, etc. It's not > exclusive, you can have multiple 2-factor keys (Yubikey, FreeOTP, > something else). On a related note, we should ask all committers to enable 2FA and then make the organization to 2FA only on github. That is a standard policy of many organizations on github. Kushal -- CPython Core Developer Director, Python Software Foundation https://kushaldas.in From stefan at bytereef.org Mon Dec 11 06:05:31 2017 From: stefan at bytereef.org (Stefan Krah) Date: Mon, 11 Dec 2017 12:05:31 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: <20171211110531.GA3069@bytereef.org> On Mon, Dec 11, 2017 at 03:46:23PM +0530, Kushal Das wrote: > On a related note, we should ask all committers to enable 2FA and then > make the organization to 2FA only on github. That is a standard policy of > many organizations on github. https://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_compromise https://gist.github.com/peternixey/1978249 I'm pretty sure my long GitHub-only password is more secure than several key-gen algorithms on smart cards ... Stefan Krah From p.f.moore at gmail.com Mon Dec 11 06:14:07 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 11 Dec 2017 11:14:07 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: On 11 December 2017 at 10:16, Kushal Das wrote: > On a related note, we should ask all committers to enable 2FA and then > make the organization to 2FA only on github. That is a standard policy of > many organizations on github. Before making such a requirement, we should ensure that doing so doesn't harm usability. For example, I have no idea how 2FA would work in conjunction with the command line git client on Windows, particularly in terms of *not* prompting on every single activity, but caching authentication appropriately. Also we should ensure that there are viable 2FA options for people in places where mobile phone signals are unreliable or unavailable (I come into that category :-() Basically, before making such a change, let's ensure it doesn't do more harm than good. Paul From victor.stinner at gmail.com Mon Dec 11 06:19:46 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 11 Dec 2017 12:19:46 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <20171211110531.GA3069@bytereef.org> References: <20171211110531.GA3069@bytereef.org> Message-ID: 2017-12-11 12:05 GMT+01:00 Stefan Krah : > https://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_compromise > https://gist.github.com/peternixey/1978249 > > I'm pretty sure my long GitHub-only password is more secure than several > key-gen algorithms on smart cards ... I wouldn't comment the attack on RSA SecurID, but I disagree that a single password is stronger than password + OTP. The principle of the 2-factor auth is that the attacker has to break two auths rather than only one. So even if you break RSA SecurID, the hacker still has to break your ultra secure GitHub-only password ;-) Victor From kushaldas at gmail.com Mon Dec 11 06:27:25 2017 From: kushaldas at gmail.com (Kushal Das) Date: Mon, 11 Dec 2017 16:57:25 +0530 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: On Mon, Dec 11, 2017 at 4:44 PM, Paul Moore wrote: > On 11 December 2017 at 10:16, Kushal Das wrote: >> On a related note, we should ask all committers to enable 2FA and then >> make the organization to 2FA only on github. That is a standard policy of >> many organizations on github. > > Before making such a requirement, we should ensure that doing so > doesn't harm usability. For example, I have no idea how 2FA would work > in conjunction with the command line git client on Windows, > particularly in terms of *not* prompting on every single activity, but > caching authentication appropriately. Also we should ensure that there > are viable 2FA options for people in places where mobile phone signals > are unreliable or unavailable (I come into that category :-() > > Basically, before making such a change, let's ensure it doesn't do > more harm than good. > Understood, the git command line tools work based on your ssh authentication. 2FA will only take place in case of user login using username/password. Even before we get into long discussions about 2FA and other things, the first step should be using a nice long passphrase (not password, but passphrase) which one can remember. And if possible, use a local password manager to store it. To create the passphrases, one can use the diceware tool ($ pip install diceware ). It is packaged for Debian, and I am working on the Fedora packaging (on review state). Kushal -- CPython Core Developer Director, Python Software Foundation https://kushaldas.in From victor.stinner at gmail.com Mon Dec 11 06:35:26 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 11 Dec 2017 12:35:26 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: 2017-12-11 11:16 GMT+01:00 Kushal Das : > On a related note, we should ask all committers to enable 2FA and then > make the organization to 2FA only on github. That is a standard policy of > many organizations on github. The first step for that would be to have an idea of how many core developers are using 2-factor auth. Administrators of the Python organization on GitHub are allowed to see that. Victor From p.f.moore at gmail.com Mon Dec 11 07:03:54 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 11 Dec 2017 12:03:54 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: On 11 December 2017 at 11:27, Kushal Das wrote: > On Mon, Dec 11, 2017 at 4:44 PM, Paul Moore wrote: >> On 11 December 2017 at 10:16, Kushal Das wrote: >>> On a related note, we should ask all committers to enable 2FA and then >>> make the organization to 2FA only on github. That is a standard policy of >>> many organizations on github. >> >> Before making such a requirement, we should ensure that doing so >> doesn't harm usability. For example, I have no idea how 2FA would work >> in conjunction with the command line git client on Windows, >> particularly in terms of *not* prompting on every single activity, but >> caching authentication appropriately. Also we should ensure that there >> are viable 2FA options for people in places where mobile phone signals >> are unreliable or unavailable (I come into that category :-() >> >> Basically, before making such a change, let's ensure it doesn't do >> more harm than good. >> > Understood, the git command line tools work based on your ssh authentication. > 2FA will only take place in case of user login using username/password. Um, I use https not ssh, as for at least some of the time I'm behind a firewall that only allows https, not ssh traffic. (I know, I'm sorry - I can probably be the worst possible corner case for *any* suggestion that gets made :-)) Paul PS I'm not against the idea as a recommended practice - just concerned about making it mandatory. From donald at stufft.io Mon Dec 11 07:29:19 2017 From: donald at stufft.io (Donald Stufft) Date: Mon, 11 Dec 2017 07:29:19 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> > On Dec 11, 2017, at 7:03 AM, Paul Moore wrote: > > Um, I use https not ssh, as for at least some of the time I'm behind a > firewall that only allows https, not ssh traffic. (I know, I'm sorry - > I can probably be the worst possible corner case for *any* suggestion > that gets made :-)) https://help.github.com/articles/providing-your-2fa-authentication-code/#through-the-command-line -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at bytereef.org Mon Dec 11 07:29:36 2017 From: stefan at bytereef.org (Stefan Krah) Date: Mon, 11 Dec 2017 13:29:36 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211110531.GA3069@bytereef.org> Message-ID: <20171211122936.GA2764@bytereef.org> On Mon, Dec 11, 2017 at 12:19:46PM +0100, Victor Stinner wrote: > 2017-12-11 12:05 GMT+01:00 Stefan Krah : > > https://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_compromise > > https://gist.github.com/peternixey/1978249 > > > > I'm pretty sure my long GitHub-only password is more secure than several > > key-gen algorithms on smart cards ... > > I wouldn't comment the attack on RSA SecurID, but I disagree that a > single password is stronger than password + OTP. > > The principle of the 2-factor auth is that the attacker has to break > two auths rather than only one. So even if you break RSA SecurID, the > hacker still has to break your ultra secure GitHub-only password ;-) Well sure, but the bureaucracy increases and ultimately the entity being protected is still a ruby on rails web app (at least that's what I have heard, I may be wrong). Ssh isn't available everywhere, I don't want to install an app or give out my phone number to half of Silicon Valley [1]. Buying a GitHub-only sim card would be an option still... Stefan Krah [1] Which is probably the real reason why 2FA is so popular. From victor.stinner at gmail.com Mon Dec 11 07:47:50 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 11 Dec 2017 13:47:50 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <20171211122936.GA2764@bytereef.org> References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> Message-ID: 2017-12-11 13:29 GMT+01:00 Stefan Krah : > Ssh isn't available everywhere, I don't want to install an app or give > out my phone number to half of Silicon Valley [1]. SMS and FreeOTP are just a few options that you have to generate/get OTP. I suggest to use Yubikey. It doesn't need to install an app or to give your phone number, but it costs 50$. The advantage is that you can use it to store your SSH and GPG keys. See also https://www.u2fzero.com/ "A secure and open source 2 factor authentication token. Designed to be affordable and reliable." Victor From antoine at python.org Mon Dec 11 07:51:19 2017 From: antoine at python.org (Antoine Pitrou) Date: Mon, 11 Dec 2017 13:51:19 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> Message-ID: <30787237-8990-b30f-79a1-c1683c8adcba@python.org> Le 11/12/2017 ? 13:47, Victor Stinner a ?crit?: > 2017-12-11 13:29 GMT+01:00 Stefan Krah : >> Ssh isn't available everywhere, I don't want to install an app or give >> out my phone number to half of Silicon Valley [1]. > > SMS and FreeOTP are just a few options that you have to generate/get OTP. > > I suggest to use Yubikey. It doesn't need to install an app or to give > your phone number, but it costs 50$. The advantage is that you can use > it to store your SSH and GPG keys. Before recommending anything you/we should first give guidelines and best practices for backup etc. If you lose your 2FA device and don't have some kind of fallback your accounts may be screwed. As usual, security can conflict with usability and the long-term availability of data. Regards Antoine. From victor.stinner at gmail.com Mon Dec 11 07:55:53 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 11 Dec 2017 13:55:53 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <30787237-8990-b30f-79a1-c1683c8adcba@python.org> References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <30787237-8990-b30f-79a1-c1683c8adcba@python.org> Message-ID: 2017-12-11 13:51 GMT+01:00 Antoine Pitrou : > Before recommending anything you/we should first give guidelines and > best practices for backup etc. > > If you lose your 2FA device and don't have some kind of fallback your > accounts may be screwed. As usual, security can conflict with usability > and the long-term availability of data. Hum, in my first email I wrote: """ * Enable 2-factor auth on GitHub and Bitbucket using Yubikey * Print two-step recovery codes on paper and keep it safe somewhere """ Using multiple tokens reduces the risk of losing access to your account. Victor From stefan at bytereef.org Mon Dec 11 07:57:05 2017 From: stefan at bytereef.org (Stefan Krah) Date: Mon, 11 Dec 2017 13:57:05 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> Message-ID: <20171211125705.GA2973@bytereef.org> On Mon, Dec 11, 2017 at 01:47:50PM +0100, Victor Stinner wrote: > 2017-12-11 13:29 GMT+01:00 Stefan Krah : > > Ssh isn't available everywhere, I don't want to install an app or give > > out my phone number to half of Silicon Valley [1]. > > SMS and FreeOTP are just a few options that you have to generate/get OTP. > > I suggest to use Yubikey. It doesn't need to install an app or to give > your phone number, but it costs 50$. The advantage is that you can use > it to store your SSH and GPG keys. I'm not a fan of hardware key generation. :-) https://en.wikipedia.org/wiki/YubiKey "In October 2017, security researchers found a vulnerability (known as ROCA) in the implementation of RSA keypair generation in a cryptographic library used by a large number of Infineon security chips. The vulnerability allows an attacker to reconstruct the private key by using the public key.[18][19] All YubiKey 4, YubiKey 4C, and YubiKey 4 nano within the revisions 4.2.6 to 4.3.4 are affected by this vulnerability.[20] Yubico publicized a tool to check if a Yubikey is affected and replaces affected tokens for free.[21]" From antoine at python.org Mon Dec 11 07:58:25 2017 From: antoine at python.org (Antoine Pitrou) Date: Mon, 11 Dec 2017 13:58:25 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <30787237-8990-b30f-79a1-c1683c8adcba@python.org> Message-ID: Le 11/12/2017 ? 13:55, Victor Stinner a ?crit?: > 2017-12-11 13:51 GMT+01:00 Antoine Pitrou : >> Before recommending anything you/we should first give guidelines and >> best practices for backup etc. >> >> If you lose your 2FA device and don't have some kind of fallback your >> accounts may be screwed. As usual, security can conflict with usability >> and the long-term availability of data. > > Hum, in my first email I wrote: > > """ > * Enable 2-factor auth on GitHub and Bitbucket using Yubikey > * Print two-step recovery codes on paper and keep it safe somewhere > """ > > Using multiple tokens reduces the risk of losing access to your account. I don't know what security experts think, but the idea of having to print and keep around recovery codes (for each and every website I enable 2FA on!) sounds completely braindead to me. Do you expect to be able to find back a random piece of paper in 5 years? I certainly don't. Regards Antoine. From alex.gaynor at gmail.com Mon Dec 11 08:00:37 2017 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 11 Dec 2017 08:00:37 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <20171211125705.GA2973@bytereef.org> References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <20171211125705.GA2973@bytereef.org> Message-ID: It's possible to generate a key on a regular computer and transfer it to a YubiKey if you prefer. (It's not like software key generation has been flawless either; [OpenSSL/Debian fiasco]. Oh well, such is life). Even if you're not going to put your SSH keys on a YubiKey, I _strongly_ encourage folks to get a Security Key (aka U2F device), of which YubiKeys are one brand, and use it for 2FA with Google/Github/Facebook/etc. In addition to (IMO) being more usable than Google Authenticator, Security Keys are resistant to phishing, which is a huge win. Alex On Mon, Dec 11, 2017 at 7:57 AM, Stefan Krah wrote: > On Mon, Dec 11, 2017 at 01:47:50PM +0100, Victor Stinner wrote: > > 2017-12-11 13:29 GMT+01:00 Stefan Krah : > > > Ssh isn't available everywhere, I don't want to install an app or give > > > out my phone number to half of Silicon Valley [1]. > > > > SMS and FreeOTP are just a few options that you have to generate/get OTP. > > > > I suggest to use Yubikey. It doesn't need to install an app or to give > > your phone number, but it costs 50$. The advantage is that you can use > > it to store your SSH and GPG keys. > > > I'm not a fan of hardware key generation. :-) > > > https://en.wikipedia.org/wiki/YubiKey > > "In October 2017, security researchers found a vulnerability (known as > ROCA) in the implementation of RSA keypair generation in a cryptographic > library used by a large number of Infineon security chips. The > vulnerability allows an attacker to reconstruct the private key by using > the public key.[18][19] All YubiKey 4, YubiKey 4C, and YubiKey 4 nano > within the revisions 4.2.6 to 4.3.4 are affected by this vulnerability.[20] > Yubico publicized a tool to check if a Yubikey is affected and replaces > affected tokens for free.[21]" > > > > > _______________________________________________ > 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/ > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Mon Dec 11 08:04:48 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 11 Dec 2017 13:04:48 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> Message-ID: On 11 December 2017 at 12:29, Donald Stufft wrote: > > On Dec 11, 2017, at 7:03 AM, Paul Moore wrote: > > Um, I use https not ssh, as for at least some of the time I'm behind a > firewall that only allows https, not ssh traffic. (I know, I'm sorry - > I can probably be the worst possible corner case for *any* suggestion > that gets made :-)) > > > > https://help.github.com/articles/providing-your-2fa-authentication-code/#through-the-command-line I use username and password and git credential manager. Uses the OS password store. I don't know of any way that 2FA integrates with that. If someone can tell me how it does (and it's as unobtrusive as, say gMail which only prompts me if I log on via a previously unused machine) then that's fine. Otherwise not so much. Paul From stefan at bytereef.org Mon Dec 11 08:07:34 2017 From: stefan at bytereef.org (Stefan Krah) Date: Mon, 11 Dec 2017 14:07:34 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <20171211125705.GA2973@bytereef.org> Message-ID: <20171211130734.GA3108@bytereef.org> On Mon, Dec 11, 2017 at 08:00:37AM -0500, Alex Gaynor wrote: > It's possible to generate a key on a regular computer and transfer it to a > YubiKey if you prefer. (It's not like software key generation has been > flawless either; [OpenSSL/Debian fiasco]. Oh well, such is life). Thanks, I did not know that. I'm still against overuse of public key cryptography (also in home banking). The reason is simply that *if* you're the victim of a key generation screwup that is not yet publicly known, you have a lot of explaining to do. This is one of the standard reasons many cryptography experts give against home banking using card readers. It puts all the responsibility on the customer/user. Stefan Krah From antoine at python.org Mon Dec 11 08:07:55 2017 From: antoine at python.org (Antoine Pitrou) Date: Mon, 11 Dec 2017 14:07:55 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <20171211125705.GA2973@bytereef.org> Message-ID: <9e1fb0ce-4bb9-429c-4639-53c928527805@python.org> Le 11/12/2017 ? 14:00, Alex Gaynor a ?crit?: > It's possible to generate a key on a regular computer and transfer it to > a YubiKey if you prefer. (It's not like software key generation has been > flawless either; [OpenSSL/Debian fiasco]. Oh well, such is life). If I have my 2FA key on a regular computer (the same that runs my password manager), is it still 2FA? Regards Antoine. From victor.stinner at gmail.com Mon Dec 11 08:29:08 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 11 Dec 2017 14:29:08 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <9e1fb0ce-4bb9-429c-4639-53c928527805@python.org> References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <20171211125705.GA2973@bytereef.org> <9e1fb0ce-4bb9-429c-4639-53c928527805@python.org> Message-ID: 2017-12-11 14:07 GMT+01:00 Antoine Pitrou : > If I have my 2FA key on a regular computer (the same that runs my > password manager), is it still 2FA? It's still more secure than password only. If your password is leaked by any mean, the 2FA still keeps you safe. >From my point of view, the risk of password leak is much higher than a compromise of your machine to steal your 2FA key. Passwords are usually handled as text, you may paste it in the wrong field of a web form, pass it as clear text (HTTP) by mistake, etc. 2FA key usually use OTP: leaking an OTP is not an issue, since it's invalidated as soon as you use it. The time window to hack your account is much shorter. It's not only a matter of 1-factor vs 2-factor, it's also the design of OTP which is more secure than passwords. It's always a matter of compromise between usability vs security. Victor From donald at stufft.io Mon Dec 11 08:41:23 2017 From: donald at stufft.io (Donald Stufft) Date: Mon, 11 Dec 2017 08:41:23 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> Message-ID: <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> > On Dec 11, 2017, at 8:04 AM, Paul Moore wrote: > >> On 11 December 2017 at 12:29, Donald Stufft wrote: >> >> On Dec 11, 2017, at 7:03 AM, Paul Moore wrote: >> >> Um, I use https not ssh, as for at least some of the time I'm behind a >> firewall that only allows https, not ssh traffic. (I know, I'm sorry - >> I can probably be the worst possible corner case for *any* suggestion >> that gets made :-)) >> >> >> >> https://help.github.com/articles/providing-your-2fa-authentication-code/#through-the-command-line > > I use username and password and git credential manager. Uses the OS > password store. I don't know of any way that 2FA integrates with that. > If someone can tell me how it does (and it's as unobtrusive as, say > gMail which only prompts me if I log on via a previously unused > machine) then that's fine. Otherwise not so much. > > Paul Did you read the linked section? You generate a limited scope access token and use that in place of your password for command line usage via https. From p.f.moore at gmail.com Mon Dec 11 09:35:39 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 11 Dec 2017 14:35:39 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> Message-ID: On 11 December 2017 at 13:41, Donald Stufft wrote: > >> On Dec 11, 2017, at 8:04 AM, Paul Moore wrote: >> >>> On 11 December 2017 at 12:29, Donald Stufft wrote: >>> >>> On Dec 11, 2017, at 7:03 AM, Paul Moore wrote: >>> >>> Um, I use https not ssh, as for at least some of the time I'm behind a >>> firewall that only allows https, not ssh traffic. (I know, I'm sorry - >>> I can probably be the worst possible corner case for *any* suggestion >>> that gets made :-)) >>> >>> >>> >>> https://help.github.com/articles/providing-your-2fa-authentication-code/#through-the-command-line >> >> I use username and password and git credential manager. Uses the OS >> password store. I don't know of any way that 2FA integrates with that. >> If someone can tell me how it does (and it's as unobtrusive as, say >> gMail which only prompts me if I log on via a previously unused >> machine) then that's fine. Otherwise not so much. >> >> Paul > > > Did you read the linked section? You generate a limited scope access token and use that in place of your password for command line usage via https. Maybe I didn't understand it. Doesn't that leave me in precisely the same situation as a username/password, in that I have a single set of credentials I can use? Or is the fact that it's tied to the specific machine the point here? If so, then thanks, I can certainly use that should someone decide that mandating 2FA is a good idea (I still maintain that recommended but not mandatory is better, as my GH account is not used solely for CPython development, so making such a change has wider effects than just for this project). Paul From chris.jerdonek at gmail.com Mon Dec 11 11:19:34 2017 From: chris.jerdonek at gmail.com (Chris Jerdonek) Date: Mon, 11 Dec 2017 11:19:34 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: On Mon, Dec 11, 2017 at 4:58 AM, Victor Stinner wrote: > ... > Oh, my explanation makes the assumption that you all already enabled > 2-factor auth on your email, right? :-) If you wasn't aware: email is > simply the *most* critical part of your whole online data. If a hacker > gets access to your email, you already lost all your online > accounts... Why do you say this? Can't this only be true for accounts that allow password recovery / reset via email? --Chris > > For Gmail users: you may have a look at > https://myaccount.google.com/security as well. Maybe remove old > services that have access to your Google account? > > > After the hack, I also generated a new SSH key, even if it wasn't > stored online and is encrypted by a passphrase. Just because I was > using the same key since many years. I chose to use the new modern > ed25519 key format. It uses an elliptic curve rather than RSA, it's a > different kind of security. While I don't know if it's more secure, I > read that it's faster :-) > > https://en.wikipedia.org/wiki/EdDSA > > I was able to use this new key formats on all services... except Launchpad. > > Changing a private SSH key isn't easy: > > * You have to install the new SSH on most services that you are using > * You have to manually remove the old SSH key from *all* services that > you are using (there is no global "SSH revokation" service...) > * I used ~/.ssh/known_hosts to get most services, but also updated > GitHub, Bitbucket, etc. > * There are a few other services like psf-salt/psf-chef where you may > also want to see your SSH key updated > * The question is then if the old SSH key must be removed... the > problem is that I never tried to keep track of services that I'm using > through SSH, so I decided to keep the old SSH key (outside ~/.ssh). In > practice, I'm only using my new SSH private since longer than 6 months > and I was never blocked. > > I also had trouble to get working SSH agent on Gnome for my ed25519 > key, but I succeeded to enable the regular ssh-agent using systemd > --user. Tell me if you want instructions for this part as well. > > 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 donald at stufft.io Mon Dec 11 13:03:32 2017 From: donald at stufft.io (Donald Stufft) Date: Mon, 11 Dec 2017 13:03:32 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> Message-ID: <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> > On Dec 11, 2017, at 9:35 AM, Paul Moore wrote: > > Maybe I didn't understand it. Doesn't that leave me in precisely the > same situation as a username/password, in that I have a single set of > credentials I can use? Or is the fact that it's tied to the specific > machine the point here? If so, then thanks, I can certainly use that > should someone decide that mandating 2FA is a good idea (I still > maintain that recommended but not mandatory is better, as my GH > account is not used solely for CPython development, so making such a > change has wider effects than just for this project). It is true that this weakens the guarantees of 2fa (as does allowing authentication using a SSH key!). In general this trade off is worth it because the authority granted by those credentials is limited (in this case, I believe you can only push/pull with them, you can?t do anything else on the account) and they?re typically only used in contexts where leaking the credential is far far harder. As a bonus, they?re not going to be shared between multiple services. So yea, it?s not as good as 2FA only everywhere, but the specific circumstances around these specific credentials makes it a reasonable usability trade off to allow them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Mon Dec 11 13:14:41 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 11 Dec 2017 18:14:41 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> Message-ID: On 11 December 2017 at 18:03, Donald Stufft wrote: > So yea, it?s not as good as 2FA only everywhere, but the specific > circumstances around these specific credentials makes it a reasonable > usability trade off to allow them. Cool. Security is always a usability vs security trade-off, and the main thing here is not to push the balance too far - we need to consider the potential issue of putting people off from contributing as well as the risk of security compromises. (Open source is a hobby activity for me - when it starts to feel too much like the day job, I start getting twitchy :-)) Paul From julien at palard.fr Mon Dec 11 13:53:01 2017 From: julien at palard.fr (Julien Palard) Date: Mon, 11 Dec 2017 13:53:01 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <30787237-8990-b30f-79a1-c1683c8adcba@python.org> Message-ID: Antoine Pitrou : > I don't know what security experts think, but the idea of having to > print and keep around recovery codes (for each and every website I > enable 2FA on!) sounds completely braindead to me. > Do you expect to be able to find back a random piece of paper in 5 > years? I certainly don't. The basic idea of 2FA is to cumulate something you know and something you have. Recovery codes are on the "something you have" side, they are not a secret, they are a possession, so it's completly OK to keep your recovery codes in your wallet. It's even a good practice to keep them in your wallet: You know where they are and they're accessible. If you break the "thing you have" you can still identify yourself even if you're out of your house. If you loose your wallet, (got it stolen, dropped in the ocean, whatever), it's no big deal: just regenerate the codes, nobody know your password, your security is not broken. In other words, the thief stealing a wallet is not the guy stealing password, so everything's good, and you have to regereate your recovery codes faster than they can meet (should be easy). To reply to you other answer, it's not really OK to store your password and your 2FA generating program on the same hardware, it breaks the "something you know and something you have" separation, it's reduced to something you have, it does no longer need two clearly separated steps to be broken. ?--? Julien Palard https://mdk.fr From antoine at python.org Mon Dec 11 13:55:53 2017 From: antoine at python.org (Antoine Pitrou) Date: Mon, 11 Dec 2017 19:55:53 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <30787237-8990-b30f-79a1-c1683c8adcba@python.org> Message-ID: <277a709f-04fd-c3a5-6943-c65fff15dc08@python.org> Hi Julien, (and welcome on this list) Le 11/12/2017 ? 19:53, Julien Palard a ?crit?: > > Recovery codes are on the "something you have" side, they are not a secret, > they are a possession, so it's completly OK to keep your recovery codes > in your wallet. A random piece of paper in my wallet may not have an extremely long lifetime (paper is fragile). And *one* piece of paper might be ok, but what if I need one for every 2FA-enabled Web site? Regards Antoine. From brett at python.org Mon Dec 11 14:26:30 2017 From: brett at python.org (Brett Cannon) Date: Mon, 11 Dec 2017 19:26:30 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <277a709f-04fd-c3a5-6943-c65fff15dc08@python.org> References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <30787237-8990-b30f-79a1-c1683c8adcba@python.org> <277a709f-04fd-c3a5-6943-c65fff15dc08@python.org> Message-ID: On Mon, 11 Dec 2017 at 10:56 Antoine Pitrou wrote: > > Hi Julien, > > (and welcome on this list) > > Le 11/12/2017 ? 19:53, Julien Palard a ?crit : > > > > Recovery codes are on the "something you have" side, they are not a > secret, > > they are a possession, so it's completly OK to keep your recovery codes > > in your wallet. > > A random piece of paper in my wallet may not have an extremely long > lifetime (paper is fragile). And *one* piece of paper might be ok, but > what if I need one for every 2FA-enabled Web site? > I print them out, trim the paper to just the codes to keep it small, and keep the codes with my passport since I'm not about to lose track of that important document. And there are only so many web sites that support 2FA so the number of pieces of paper isn't massive. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Mon Dec 11 14:52:54 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 11 Dec 2017 14:52:54 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> Message-ID: <20171211195255.29F601310024@webabinitio.net> On Mon, 11 Dec 2017 18:14:41 +0000, Paul Moore wrote: > On 11 December 2017 at 18:03, Donald Stufft wrote: > > So yea, it???s not as good as 2FA only everywhere, but the specific > > circumstances around these specific credentials makes it a reasonable > > usability trade off to allow them. > > Cool. Security is always a usability vs security trade-off, and the > main thing here is not to push the balance too far - we need to > consider the potential issue of putting people off from contributing > as well as the risk of security compromises. (Open source is a hobby > activity for me - when it starts to feel too much like the day job, I > start getting twitchy :-)) Indeed. If 2fa is required for contribution to CPython, I'll stop contributing. Granted, I haven't done many merges lately, but a few is a bigger number than zero :) --David From donald at stufft.io Mon Dec 11 14:56:21 2017 From: donald at stufft.io (Donald Stufft) Date: Mon, 11 Dec 2017 14:56:21 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <20171211195255.29F601310024@webabinitio.net> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> Message-ID: <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> > On Dec 11, 2017, at 2:52 PM, R. David Murray wrote: > > If 2fa is required for contribution to CPython, I'll stop > contributing. I?m curious why? I have it on and 99% of the time you don?t even notice because you?re already logged into GitHub and pushes/pulls don?t require it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Mon Dec 11 14:59:57 2017 From: guido at python.org (Guido van Rossum) Date: Mon, 11 Dec 2017 11:59:57 -0800 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> Message-ID: Whatever happens I don't want to lose core devs over this. (That said I have 2fa on myself -- Dropbox pretty requires this -- and it's painless for me. But I can totally understand that it's not the same experience for everyone.) On Mon, Dec 11, 2017 at 11:56 AM, Donald Stufft wrote: > > On Dec 11, 2017, at 2:52 PM, R. David Murray > wrote: > > If 2fa is required for contribution to CPython, I'll stop > contributing. > > > I?m curious why? I have it on and 99% of the time you don?t even notice > because you?re already logged into GitHub and pushes/pulls don?t require it. > > _______________________________________________ > 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 steve.dower at python.org Mon Dec 11 15:04:45 2017 From: steve.dower at python.org (Steve Dower) Date: Mon, 11 Dec 2017 12:04:45 -0800 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> Message-ID: <0c2cefd5-50a2-5416-2e96-cedb53e75a2f@python.org> On 11Dec2017 0504, Paul Moore wrote: > On 11 December 2017 at 12:29, Donald Stufft wrote: >> >> On Dec 11, 2017, at 7:03 AM, Paul Moore wrote: >> >> Um, I use https not ssh, as for at least some of the time I'm behind a >> firewall that only allows https, not ssh traffic. (I know, I'm sorry - >> I can probably be the worst possible corner case for *any* suggestion >> that gets made :-)) >> >> >> >> https://help.github.com/articles/providing-your-2fa-authentication-code/#through-the-command-line > > I use username and password and git credential manager. Uses the OS > password store. I don't know of any way that 2FA integrates with that. > If someone can tell me how it does (and it's as unobtrusive as, say > gMail which only prompts me if I log on via a previously unused > machine) then that's fine. Otherwise not so much. On Windows, recent versions of git will pop up GUI login prompt that can do 2FA. Then it gets cached as normal (and may occasionally pop up again when the token expires). Make sure your copy of git is up to date (which you should do anyway because of the recent vulnerabilities in submodule resolution) and then 2FA is totally doable. (Only caveat, I get my copy of git for Windows via the VS 2017 installer. I'm pretty sure nothing extra gets added to this, but it's possible that a special credential manager does.) Cheers, Steve From rdmurray at bitdance.com Mon Dec 11 15:11:47 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 11 Dec 2017 15:11:47 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <20171211195255.29F601310024@webabinitio.net> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> Message-ID: <20171211201148.9FFFF1310023@webabinitio.net> On Mon, 11 Dec 2017 14:52:54 -0500, "R. David Murray" wrote: > Indeed. If 2fa is required for contribution to CPython, I'll stop > contributing. Granted, I haven't done many merges lately, but a few > is a bigger number than zero :) And in case you think this means I don't consider security important: I have been using strong, unique-per-site passwords (and in many cases unique usernames/emails) for many years, and I run my own email server. --David Aside: something I have never understood is the relatively recent craze for enter-username-first-then-go-to-password-screen. Most of the implementations I have encountered tell you if the username is unknown. That reduces the cracker's search space by a considerable amount. Using your email address as the account id has the same problem, magnified. I had already started using unique usernames/emails before that trend happened, to battle spam, but it certainly reinforced my motivation for doing so. I unfortunately haven't gotten around to backfilling a lot of the sites I did sign up to using my primary email address :( From julien at palard.fr Mon Dec 11 15:15:50 2017 From: julien at palard.fr (Julien Palard) Date: Mon, 11 Dec 2017 15:15:50 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <277a709f-04fd-c3a5-6943-c65fff15dc08@python.org> References: <20171211122936.GA2764@bytereef.org> <30787237-8990-b30f-79a1-c1683c8adcba@python.org> <277a709f-04fd-c3a5-6943-c65fff15dc08@python.org> Message-ID: Antoine Pitrou : > A random piece of paper in my wallet may not have an extremely long > lifetime (paper is fragile). And one piece of paper might be ok, but > what if I need one for every 2FA-enabled Web site? It's a legitimate question, so I'm taking mine out right now to check. I use a single folded paper of like 20cm?10cm, so folded twice it take less than a standard card, and it's in a good shape as it's stored in a flat compartment of my wallet (I'm having it since like 6 months, I do not remember the "bad shape" of my previous one when I changed it). I'm currently having 7 sevices on it, with 6 codes for each of them, there's still room for 4 services if I dont start using both sides. It's handwritten as I didn't had a printer at that time (yes, it's a PITA to write them all, I now have a printer and try with it next time). So from my point of view it's totally OK to store them as a folded sheet of paper in a wallet, as long as you can print and cut them: I agree, handwriting them is really something I would not recommend. Also, renewing all codes (if your wallet get stolen) take a huge amount of time if you have codes for, say more than 5 sevices, it's something to consider, but does not happen often. While I'm at it, applications like Google Authenticator does *not* display favicon or whatever, just the name of the service, it starts to be annoying up to 10 registered services (almost two screen long of OTP being generated). Also, I consider receiving OTP over SMS a bad solution: you may not receive them in some places or some countries besides being relatively easy to intercept (by someone really wanting them, they could just buy a big wrench for $10 at this point). ?--? Julien Palard https://mdk.fr ? From alex.gaynor at gmail.com Mon Dec 11 15:19:48 2017 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 11 Dec 2017 15:19:48 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <20171211201148.9FFFF1310023@webabinitio.net> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <20171211201148.9FFFF1310023@webabinitio.net> Message-ID: The reason for the username-then-a-new-page-for-password flow in many cases is that the sites have multiple flows depending on your username! The GMail login page for example can send you to either the password page since you're a consumer account, the password page because you're a GSuite account using Google login, an off-site page since you're a GSuite using SAML. (This is ignoring the need to choose 2FA flows -- TOTP vs SMS vs Security Key!) Alex On Mon, Dec 11, 2017 at 3:11 PM, R. David Murray wrote: > On Mon, 11 Dec 2017 14:52:54 -0500, "R. David Murray" < > rdmurray at bitdance.com> wrote: > > Indeed. If 2fa is required for contribution to CPython, I'll stop > > contributing. Granted, I haven't done many merges lately, but a few > > is a bigger number than zero :) > > And in case you think this means I don't consider security important: > I have been using strong, unique-per-site passwords (and in many cases > unique usernames/emails) for many years, and I run my own email server. > > --David > > Aside: something I have never understood is the relatively recent > craze for enter-username-first-then-go-to-password-screen. Most of the > implementations I have encountered tell you if the username is unknown. > That reduces the cracker's search space by a considerable amount. Using > your email address as the account id has the same problem, magnified. > I had already started using unique usernames/emails before that trend > happened, to battle spam, but it certainly reinforced my motivation for > doing so. I unfortunately haven't gotten around to backfilling a lot > of the sites I did sign up to using my primary email address :( > _______________________________________________ > 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/ > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Mon Dec 11 15:26:40 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 11 Dec 2017 15:26:40 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> Message-ID: <20171211202640.85C721310023@webabinitio.net> On Mon, 11 Dec 2017 14:56:21 -0500, Donald Stufft wrote: > > > On Dec 11, 2017, at 2:52 PM, R. David Murray wrote: > > > > If 2fa is required for contribution to CPython, I'll stop > > contributing. > > I???m curious why? I have it on and 99% of the time you don???t even > notice because you???re already logged into GitHub and pushes/pulls > don???t require it. I had to use 2FA when working for a corporate client, and it was very annoying. The fact that pushes and pulls don't require it helps, but also makes it considerably less important. But I suppose that fundamentally I do not want my security tied to a possession. --David From p.f.moore at gmail.com Mon Dec 11 16:37:20 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 11 Dec 2017 21:37:20 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <20171211122936.GA2764@bytereef.org> <30787237-8990-b30f-79a1-c1683c8adcba@python.org> <277a709f-04fd-c3a5-6943-c65fff15dc08@python.org> Message-ID: On 11 December 2017 at 20:15, Julien Palard via python-committers wrote: > Antoine Pitrou : >> A random piece of paper in my wallet may not have an extremely long >> lifetime (paper is fragile). And one piece of paper might be ok, but >> what if I need one for every 2FA-enabled Web site? > > It's a legitimate question, so I'm taking mine out right now to check. Here's a question (disclaimer: I'm *not* saying I disagree with 2FA, or strong security, or anything like that, I'm genuinely curious about the usability trade-offs based on my experience). I have a piece of paper with some Google account recovery keys on it. I think it's in my wallet (it was last time I looked but that's literally years ago). So, what if I've lost it? As I understand it, if I lose my access for any reason (phone broke irrecoverably is the example that happened to me a few months ago), I need those keys to get access, but I don't know any longer if I have them. And if I don't, I'm screwed. So surely there's an additional requirement that I keep track of my recovery keys, so I *know* if they get lost? Password/identity management is a *huge* burden in these days of every website under the sun needing a unique login. Even just classifying your accounts as "critical", "important", "useful", "minor" and "throwaway" takes significant effort. Password managers are basically the only scalable solution I know of, and they have their own problems (online ones can be compromised themselves, personal ones don't always work on all devices, and sharing the password database is a non-trivial issue). I already need to know one thing (the password DB passphrase) and have another (the DB itself). 2FA essentially adds a third factor, not a second (yes, I know that's not precisely correct). Anyway, I've said enough - you get my point. People should be allowed to make their own judgments on risk vs usability. IMO, we should focus on: 1. If we grant core dev status, we should factor in whether we think the prospective candidate understands the responsibility in terms of security (I'd be surprised if anyone thought we didn't already do that). 2. Because we're on a shared infrastructure (github) we can't mandate how developer accounts are configured without considering how that affects a user's *other* activities [1]. Paul [1] I can expand on this, but it's somewhat off-topic and also not something I'd want to discuss on a public list, so ask me privately if you're interested in my specific case. From greg at krypto.org Mon Dec 11 20:17:50 2017 From: greg at krypto.org (Gregory P. Smith) Date: Tue, 12 Dec 2017 01:17:50 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <20171211202640.85C721310023@webabinitio.net> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> Message-ID: On Mon, Dec 11, 2017 at 12:26 PM R. David Murray wrote: > On Mon, 11 Dec 2017 14:56:21 -0500, Donald Stufft > wrote: > > > > > On Dec 11, 2017, at 2:52 PM, R. David Murray > wrote: > > > > > > If 2fa is required for contribution to CPython, I'll stop > > > contributing. > > > > I?m curious why? I have it on and 99% of the time you don?t even > > notice because you?re already logged into GitHub and pushes/pulls > > don?t require it. > > I had to use 2FA when working for a corporate client, and it was > very annoying. The fact that pushes and pulls don't require it > helps, but also makes it considerably less important. > Please Don't let *that* experience color your 2FA opinion. Not everyone $random_corp does a good job of it. It does not have to be annoying. Github's and Google's are examples of 2FA done right that is not annoying (using U2F). But I suppose that fundamentally I do not want my security tied to a > possession. > *2FA doesn't need to be tied to a single possession.* You are not limited to a single second factor thing. You can have plentiful different two factor methods set up at once. This is normal. ex: A printed recovery code at the very least as a second second factor. Have multiple U2F USB tokens tied to your account? Yes. I do that all the time on all accounts. Heck, a photo/scan/screenshot of backup one time codes stored as a public image somewhere with no password authentication for the world to see on an http server still counts. As laughable as that is, it is *still* much better than not having 2FA enabled at all. Because it isn't going to be an automated attack at that point. *Any* 2FA is much better than no 2FA. When (not if) your login/password is compromised, it is rarely your own fault. But your account and all of your data can be gone in a heartbeat as soon as anyone or anything malicious chooses to make it so on whatever selection of accounts they choose to victimize. Often irrecoverably. With 2FA enabled, that is much less likely to happen to you. Try it. You will remain happy. I recommend the https://www.yubico.com/product/yubikey-neo/ as a primary U2F token because it even works with Chrome on Android phones via NFC when you need to re-auth there. That is a more expensive one, there are $10-20 alternative vanilla U2F USB tokens. I have some of those as backups. The "nano" style keys that you just leave in the USB port of all computers you use regularly are also a nice solution. no need to find and pull out the key, it is just present in your computers (it requires a physical touch to prevent remote access). Which 2FA methods to choose is an individual choice, but in my experience since the U2F keys came out, I'm less inclined to use any service that doesn't support them as all other solutions are a worse user experience for me. IMNSHO, the PSF *should* be able to buy one or two U2F tokens for any committer who needs them. This should not depend on a policy of 2FA use, it would just be a way to promote good security practices among committers to make us all better off. -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Tue Dec 12 04:42:56 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 12 Dec 2017 10:42:56 +0100 Subject: [python-committers] 2FA: only needed at the *first* GitHub login, not needed for commits Message-ID: Hi, On the "Security: please enable 2-factor authentication on GitHub and your email" thread that I started, I see many people afraid of being annoyed everyday by 2FA (2-factor authentication, called "Authentication code" in GitHub). Let me explain how GitHub uses 2FA. * Let's say that you are not logged on GitHub (or log out to test yourself). * Log in GitHub: enter email and password, then you are asked for an "Authentication code". * You're logged in, congrats :-) * Close Firefox * Open Firefox, go to GitHub: you are already logged in. No more password nor Authentication code asked. Hum... that's it :-) I don't know how long the GitHub cookie remains valid, but it's very rare (maybe once per month? or once every 3 months??) for me to have to log in again. And usually, it's because I log out on purpose. Ok, now you can to push a pull request using SSH: * Step 1: git push (...) * There is no step 2 :-) There is no 2FA here. If I understood correctly, for HTTPS, there is no 2FA neither. So where is the 2FA? * New log in The 2FA is not needed for: * (If you are already logged in) Disabling 2FA doesn't require an authentication code. I just checked for you :-) * Adding a new SSH key to your account only requires your password, but the authentication code is also accepted instead of the password So what is the point of 2FA? It protects the log in. If an attacker has your password without the 2FA key, they are unable to log in. >From what I see, the 2FA doesn't protect against pushing commits if the attacker steal your SSH key or your HTTPS password. My understanding is that it's more common to get a password stolen than a SSH key. While you have to write the password regulary in web forms, GitHub only requires your SSH *public key* (only asked you, when adding a new key). The risk of leaking a SSH private key by mistake is much lower. For example, a browser doesn't ask you to store your SSH private key, only your password. For HTTPS: well, try to avoid HTTPS and prefer SSH? :-) A few months ago, using a Yubikey is Firefox required a plugin. Good news: since Firefox 57 (or even Firefox 56), U2F support is now builtin! But it's still experimental and so disabled by default (it's a simple flag that has to be set to true in about:config): https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/ Google has the same 2FA design. It stores a cookie and so once you are logged on your computer, the 2FA is no more used. There is a check box like "[x] Remember this computer" or something like that. The 2FA matters you someone tries to use your password on a different computer. At work, I have a different experience with 2FA. It's much more stricter. I have to use my 2FA at least once a day, or more frequently depending on the services that I have to use. So yeah, I understand that some people who already suffer from that don't want to be annoyed on the Python project. Victor From victor.stinner at gmail.com Tue Dec 12 04:56:44 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 12 Dec 2017 10:56:44 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: Message-ID: 2017-12-11 17:19 GMT+01:00 Chris Jerdonek : > Why do you say this? Can't this only be true for accounts that allow > password recovery / reset via email? > > --Chris While I didn't check, but I'm quite sure that the email quickly enters into the play when you want to recover your GitHub account when you lost everything (password, 2FA key, recovery code). At least, the email was the key to break the security in one "I have been hacked" article. Hum, I think that it was this article: https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/ The story is related to "password reset": Google (Gmail), Apple, Twitter, Amazon, etc. Victor From stefan at bytereef.org Tue Dec 12 05:00:32 2017 From: stefan at bytereef.org (Stefan Krah) Date: Tue, 12 Dec 2017 11:00:32 +0100 Subject: [python-committers] 2FA: only needed at the *first* GitHub login, not needed for commits In-Reply-To: References: Message-ID: <20171212100032.GA3352@bytereef.org> On Tue, Dec 12, 2017 at 10:42:56AM +0100, Victor Stinner wrote: > Let me explain how GitHub uses 2FA. > > * Let's say that you are not logged on GitHub (or log out to test yourself). > * Log in GitHub: enter email and password, then you are asked for an > "Authentication code". > * You're logged in, congrats :-) > * Close Firefox > * Open Firefox, go to GitHub: you are already logged in. No more > password nor Authentication code asked. Well, my security model is different. I have full disk encryption with a long passphrase. I shut down the computer when I leave, so I have to enter that passphrase several times a day. I have an encrypted text file that contains per-website passwords, protected by another long passphrase. I have to decrypt that file at least once after booting. Finally, due to the garbage that modern browsers store (run rsync and watch what is accumulated even in a day), I clear all the history etc. when Firefox is closed. This means that I have to log in ***multiple times into GitHub per day***. My GitHub password should be only on GitHub, so when there's a breach GitHub is already pwned (which it has been in the past but the prevailing doctrine does not permit to mention it, and if anyone dares to he is ignored). Given the snake oil history in crypto products (Crypto AG, RSA SecureID, Infineon chips, closed source in YubiKey), quite franky MY security model won't allow inserting such a product into an USB slot. Stefan Krah From victor.stinner at gmail.com Tue Dec 12 05:14:54 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 12 Dec 2017 11:14:54 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <20171211125705.GA2973@bytereef.org> References: <20171211110531.GA3069@bytereef.org> <20171211122936.GA2764@bytereef.org> <20171211125705.GA2973@bytereef.org> Message-ID: 2017-12-11 13:57 GMT+01:00 Stefan Krah : > I'm not a fan of hardware key generation. :-) > > https://en.wikipedia.org/wiki/YubiKey > > "In October 2017, security researchers found a vulnerability (known as ROCA) in the implementation of RSA keypair generation in a cryptographic library used by a large number of Infineon security chips. The vulnerability allows an attacker to reconstruct the private key by using the public key.[18][19] All YubiKey 4, YubiKey 4C, and YubiKey 4 nano within the revisions 4.2.6 to 4.3.4 are affected by this vulnerability.[20] Yubico publicized a tool to check if a Yubikey is affected and replaces affected tokens for free.[21]" FYI it seems like only RSA private key generated by old Yubikey keys are vulnerable to the ROCA attack. OTP authentication is not affected. See https://www.yubico.com/keycheck/ for more information. "ROCA: Return Of the Coppersmith Attack": https://lwn.net/Articles/738896/ As I wrote, I chose to use ed25519 for my new SSH key. Maybe it was a good idea :-) Victor From victor.stinner at gmail.com Tue Dec 12 07:50:01 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 12 Dec 2017 13:50:01 +0100 Subject: [python-committers] Fwd: What happens if I loose my password, 2FA key and recovery key In-Reply-To: References: <5a2fa66e6c5ba_222b210648af10724b7@unicorn-3275483868-v315v.mail> Message-ID: For the ones who are worried about losing all credentials for their GitHub account, here are some official answers from GitHub support. Victor ---------- Forwarded message ---------- From: Michael (GitHub Staff) Date: 2017-12-12 11:05 GMT+01:00 Subject: Re: What happens if I loose my password, 2FA key and recovery key To: Victor Stinner Hi Victor, Thanks for getting in touch. To address your questions: The question is what happens if you loose your password, your 2FA key and your recovery key... Ok, it's unlikely, but it's a real question. If you were to lose access to all of your 2FA credentials, I'm afraid we wouldn't be able to disable 2FA for you, for security reasons. For this reason, we recommend setting up one or more fallbacks. One way of safeguarding recovery keys is storing them in an encrypted password manager like 1Password or LastPass, which often have cloud backup capabilities. The second question is if the email account comes into the play as the last attempt to recover access to the GitHub account. The email and password associated with an account provide one factor of authentication. If 2FA is enabled, a second factor is required. In the case of someone losing access to all 2FA credentials, but still having access to the email associated with an account, we aren't able to disable 2FA, but can release the email address from the account. This would then allow the user to register the email address to a new account. Additionally, any contributions associated with that email address would follow along to the new account. At present, we have a range of fallbacks, which I'll list below. It's a good idea to use more than one, while also being mindful of not creating too much exposure. *Download your recovery codes.* This is far and away the best way to make sure you don't get locked out of your account. If you ever disable and then re-enable 2FA, be sure to download the new codes we generate as the old ones will no longer work. https://help.github.com/articles/downloading-your-two-factor-authentication- recovery-codes *Set a fallback number.* As long as your phone wasn't lost, you'll be able to regain access to your account in the amount of time it takes to receive an SMS. https://help.github.com/articles/setting-a-fallback-authentication-number *Add a security key.* Phone got stolen *and* you lost your recovery codes? Today is turning into a rough day, but you'll still have access to your account if you have a FIDO U2F security key added to your account. https://help.github.com/articles/configuring-two-factor-authentication-via- fido-u2f *Store a recovery token* If you use Facebook, you're now able to store a 2FA recovery token with your account. Here's how: https://help.github.com/articles/generating-and-storing-an-account-recovery- token *Set up an SSH key* We?re sometimes able to recover an otherwise locked out account if there?s an SSH key set up. You can add one by heading to: https://help.github.com/articles/adding-a-new-ssh-key- to-your-github-account/ Let me know if you have any questions or if there's anything else we can help with! Best regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Tue Dec 12 08:07:13 2017 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 12 Dec 2017 14:07:13 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> Message-ID: <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> I'm with David on this one. 2FA is good for admin accounts, but doesn't add much protection for regular committers. Think of what you're trying to protect against: git checkins are all audited and can easily be undone. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Dec 12 2017) >>> 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 antoine at python.org Tue Dec 12 08:09:52 2017 From: antoine at python.org (Antoine Pitrou) Date: Tue, 12 Dec 2017 14:09:52 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> Message-ID: <4a7413ac-0c4e-6ed8-b5d4-605a78e6773b@python.org> And I'm not even sure it's possible to push directly without opening a PR... All the arguments have been heard now and it would be nice if this thread could die. Le 12/12/2017 ? 14:07, M.-A. Lemburg a ?crit?: > I'm with David on this one. 2FA is good for admin accounts, but > doesn't add much protection for regular committers. Think of what > you're trying to protect against: git checkins are all audited and > can easily be undone. > From p.f.moore at gmail.com Tue Dec 12 08:10:37 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 12 Dec 2017 13:10:37 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> Message-ID: On 12 December 2017 at 13:07, M.-A. Lemburg wrote: > I'm with David on this one. 2FA is good for admin accounts, but > doesn't add much protection for regular committers. Think of what > you're trying to protect against: git checkins are all audited and > can easily be undone. Indeed. I'd rather have a password-protected account that I can recover using my (2FA protected) email, than a second set of 2FA credentials that I have to manage to avoid the risk of being 100% locked out of github. Paul From christian at cheimes.de Tue Dec 12 08:04:42 2017 From: christian at cheimes.de (Christian Heimes) Date: Tue, 12 Dec 2017 14:04:42 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> Message-ID: <54c003bc-74f9-b145-1887-571bbc7853b3@cheimes.de> On 2017-12-12 02:17, Gregory P. Smith wrote: > On Mon, Dec 11, 2017 at 12:26 PM R. David Murray > wrote: > > On Mon, 11 Dec 2017 14:56:21 -0500, Donald Stufft > wrote: > > > > > On Dec 11, 2017, at 2:52 PM, R. David Murray > > wrote: > > > > > > If 2fa is required for contribution to CPython, I'll stop > > > contributing. > > > > I?m curious why? I have it on and 99% of the time you don?t even > > notice because you?re already logged into GitHub and pushes/pulls > > don?t require it. > > I had to use 2FA when working for a corporate client, and it was > very annoying.? The fact that pushes and pulls don't require it > helps, but also makes it considerably less important. > > ? > Please Don't let /that/ experience color your 2FA opinion.? Not everyone > $random_corp does a good job of it. > > It does not have to be annoying.? Github's and Google's are examples of > 2FA done right that is not annoying (using U2F). > > But I suppose that fundamentally I do not want my security tied to a > possession. > > > *2FA doesn't need to be tied to a single possession.*? You are not > limited to a single second factor thing.? You can have plentiful > different two factor methods set up at once.? This is normal.? ex: A > printed recovery code at the very least as a second second factor.? Have > multiple U2F USB tokens tied to your account? Yes. I do that all the > time on all accounts. > > Heck, a photo/scan/screenshot of backup one time codes stored as a > public image somewhere with no password authentication for the world to > see on an http server still counts.? As laughable as that is, it is > *still* much better than not having 2FA enabled at all.? Because it > isn't going to be an automated attack at that point. > > /Any/ 2FA is much better than no 2FA. > > When (not if) your login/password is compromised, it is rarely your own > fault. But your account and all of your data can be gone in a heartbeat > as soon as anyone or anything malicious chooses to make it so on > whatever selection of accounts they choose to victimize. Often > irrecoverably. With 2FA enabled, that is much less likely to happen to you. > > Try it. You will remain happy. > > I recommend the?https://www.yubico.com/product/yubikey-neo/?as a primary > U2F token because it even works with Chrome on Android phones via NFC > when you need to re-auth there.? That is a more expensive one, there are > $10-20 alternative vanilla U2F USB tokens. I have some of those as > backups. The "nano" style keys that you just leave in the USB port of > all computers you use regularly are also a nice solution. no need to > find and pull out the key, it is just present in your computers (it > requires a physical touch to prevent remote access). > > Which 2FA methods to choose is an individual choice, but in my > experience since the U2F keys came out, I'm less inclined to use any > service that doesn't support them as all other solutions are a worse > user experience for me. > > IMNSHO, the PSF /should/ be able to buy one or two U2F tokens for any > committer who needs them.? This should not depend on a policy of 2FA > use, it would just be a way to promote good security practices among > committers? to make us all better off. +1 If you don't the trust closed-source Yubico hardware, there is plenty of other hardware out. https://www.nitrokey.com/ is good German engineering with fully open-sourced hardware and software. Adam has compiled a nice list of U2F and 2FA tokens, too. https://www.imperialviolet.org/2017/10/08/securitykeytest.html Christian From stefan at bytereef.org Tue Dec 12 08:22:17 2017 From: stefan at bytereef.org (Stefan Krah) Date: Tue, 12 Dec 2017 14:22:17 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <54c003bc-74f9-b145-1887-571bbc7853b3@cheimes.de> References: <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> <54c003bc-74f9-b145-1887-571bbc7853b3@cheimes.de> Message-ID: <20171212132217.GA7633@bytereef.org> On Tue, Dec 12, 2017 at 02:04:42PM +0100, Christian Heimes wrote: > If you don't the trust closed-source Yubico hardware, there is plenty of > other hardware out. https://www.nitrokey.com/ is good German engineering > with fully open-sourced hardware and software. > > Adam has compiled a nice list of U2F and 2FA tokens, too. > https://www.imperialviolet.org/2017/10/08/securitykeytest.html The PSF then also must provide developer laptops along with the usb thingy. I would assume that in extremely security conscious enviroments plugging *anything* into an USB port is forbidden (if there are USB ports at all). Stefan Krah From brett at python.org Tue Dec 12 11:12:27 2017 From: brett at python.org (Brett Cannon) Date: Tue, 12 Dec 2017 16:12:27 +0000 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> Message-ID: On Tue, Dec 12, 2017, 05:07 M.-A. Lemburg, wrote: > I'm with David on this one. 2FA is good for admin accounts, but > doesn't add much protection for regular committers. Think of what > you're trying to protect against: git checkins are all audited and > can easily be undone. > But David has an admin account for the repo. ? Anyway, it sounds like we're not going to force this in anyone, but perhaps it might be worth considering for admin accounts since they control whether force pushes are possible. -brett > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Dec 12 2017) > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > _______________________________________________ > python-committers mailing list > 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 Tue Dec 12 11:21:48 2017 From: antoine at python.org (Antoine Pitrou) Date: Tue, 12 Dec 2017 17:21:48 +0100 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> Message-ID: If some people are inclined to push for 2FA, I think it would be more productive to write some kind of document giving advice and suggestions and addressing all potential issues (such as backups, cross-platform compatibility, software integration with various tools, etc.). For example I have 2FA enabled on Github but I just learned that U2F keys are supposed to work with Firefox 57.0. Regards Antoine. Le 12/12/2017 ? 17:12, Brett Cannon a ?crit?: > > > On Tue, Dec 12, 2017, 05:07 M.-A. Lemburg, > wrote: > > I'm with David on this one. 2FA is good for admin accounts, but > doesn't add much protection for regular committers. Think of what > you're trying to protect against: git checkins are all audited and > can easily be undone. > > > But David has an admin account for the repo. ? Anyway, it sounds like > we're not going to force this in anyone, but perhaps it might be worth > considering for admin accounts since they control whether force pushes > are possible. > > -brett > > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Dec 12 2017) > >>> Python Projects, Coaching and Consulting ...? http://www.egenix.com/ > >>> Python Database Interfaces ...? ? ? ? ? ?http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ...? ? ? ? ? ?http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > ? ?eGenix.com Software, Skills and Services GmbH? Pastor-Loeh-Str.48 > ? ? D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > ? ? ? ? ? ?Registered at Amtsgericht Duesseldorf: HRB 46611 > ? ? ? ? ? ? ? ?http://www.egenix.com/company/contact/ > ? ? ? ? ? ? ? ? ? ? ? http://www.malemburg.com/ > > _______________________________________________ > python-committers mailing list > 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 alex.gaynor at gmail.com Tue Dec 12 18:57:32 2017 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 12 Dec 2017 18:57:32 -0500 Subject: [python-committers] Security: please enable 2-factor authentication on GitHub and your email In-Reply-To: References: <7A58D68F-3C7B-46A2-85C2-BE79896211B4@stufft.io> <34297AF2-D23D-49D6-9694-F62C835602A5@stufft.io> <135BE494-2010-44FB-874F-211ADE80E081@stufft.io> <20171211195255.29F601310024@webabinitio.net> <7C1F8DA7-3057-43C3-8BDF-9423C8A37376@stufft.io> <20171211202640.85C721310023@webabinitio.net> <213ec3d0-ab50-c5d1-998d-c2077acb29e5@egenix.com> Message-ID: They require a preference to be enabled, but yeah, Security Keys in Firefox Quantum ? https://mobile.twitter.com/jamespugjones/status/912314952232267777 Alex On Tue, Dec 12, 2017 at 11:21 AM, Antoine Pitrou wrote: > > If some people are inclined to push for 2FA, I think it would be more > productive to write some kind of document giving advice and suggestions > and addressing all potential issues (such as backups, cross-platform > compatibility, software integration with various tools, etc.). For > example I have 2FA enabled on Github but I just learned that U2F keys > are supposed to work with Firefox 57.0. > > Regards > > Antoine. > > > Le 12/12/2017 ? 17:12, Brett Cannon a ?crit : > > > > > > On Tue, Dec 12, 2017, 05:07 M.-A. Lemburg, > > wrote: > > > > I'm with David on this one. 2FA is good for admin accounts, but > > doesn't add much protection for regular committers. Think of what > > you're trying to protect against: git checkins are all audited and > > can easily be undone. > > > > > > But David has an admin account for the repo. ? Anyway, it sounds like > > we're not going to force this in anyone, but perhaps it might be worth > > considering for admin accounts since they control whether force pushes > > are possible. > > > > -brett > > > > > > -- > > Marc-Andre Lemburg > > eGenix.com > > > > Professional Python Services directly from the Experts (#1, Dec 12 > 2017) > > >>> Python Projects, Coaching and Consulting ... > http://www.egenix.com/ > > >>> Python Database Interfaces ... > http://products.egenix.com/ > > >>> Plone/Zope Database Interfaces ... > http://zope.egenix.com/ > > ____________________________________________________________ > ____________ > > > > ::: We implement business ideas - efficiently in both time and costs > ::: > > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > > Registered at Amtsgericht Duesseldorf: HRB 46611 > > http://www.egenix.com/company/contact/ > > http://www.malemburg.com/ > > > > _______________________________________________ > > python-committers mailing list > > 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/ > > > _______________________________________________ > 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/ > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Wed Dec 13 09:33:35 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 13 Dec 2017 06:33:35 -0800 Subject: [python-committers] Saying hello as a new core dev In-Reply-To: References: Message-ID: Hello Julien, Welcome to this list, and good to meet you! -- Senthil On Sat, Dec 9, 2017 at 12:56 PM, Julien Palard via python-committers < python-committers at python.org> wrote: > Hi, python-committers! > > That's huge, for me, to receive this notification "Your now a core > developer, congratulations!" thanks everyone here! > > And waw, your messages in your votes to bring me in are heartwarming, as I > said yesterday they validate, again and again, the ancient adage "Come for > the language, stay for the community". > > ?-- > Julien Palard > https://mdk.fr > > _______________________________________________ > 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 andrew.svetlov at gmail.com Wed Dec 13 10:22:18 2017 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Wed, 13 Dec 2017 15:22:18 +0000 Subject: [python-committers] Saying hello as a new core dev In-Reply-To: References: Message-ID: Welcome! On Wed, Dec 13, 2017 at 4:33 PM Senthil Kumaran wrote: > Hello Julien, > > Welcome to this list, and good to meet you! > > -- > Senthil > > > On Sat, Dec 9, 2017 at 12:56 PM, Julien Palard via python-committers < > python-committers at python.org> wrote: > >> Hi, python-committers! >> >> That's huge, for me, to receive this notification "Your now a core >> developer, congratulations!" thanks everyone here! >> >> And waw, your messages in your votes to bring me in are heartwarming, as >> I said yesterday they validate, again and again, the ancient adage "Come >> for the language, stay for the community". >> >> ?-- >> Julien Palard >> https://mdk.fr >> >> _______________________________________________ >> 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/ > -- Thanks, Andrew Svetlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Thu Dec 14 11:27:50 2017 From: antoine at python.org (Antoine Pitrou) Date: Thu, 14 Dec 2017 17:27:50 +0100 Subject: [python-committers] AppVeyor builds broken Message-ID: Hello, It seems AppVevor builds (and generally Windows builds) have been broken for some time with a failure in test_distutils: https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.9471#L2040 ====================================================================== ERROR: test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\cpython\lib\distutils\tests\test_bdist_wininst.py", line 24, in test_get_exe_bytes exe_file = cmd.get_exe_bytes() File "C:\projects\cpython\lib\distutils\command\bdist_wininst.py", line 361, in get_exe_bytes f = open(filename, "rb") FileNotFoundError: [Errno 2] No such file or directory: 'C:\\projects\\cpython\\lib\\distutils\\command\\wininst-14.12.exe' ---------------------------------------------------------------------- Regards Antoine. From victor.stinner at gmail.com Thu Dec 14 11:31:43 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 14 Dec 2017 17:31:43 +0100 Subject: [python-committers] AppVeyor builds broken In-Reply-To: References: Message-ID: Hi, I already fixed the bug in 3.6 and master. You may still the bug if you don't rebase your change to get the fix. https://bugs.python.org/issue32302 Victor 2017-12-14 17:27 GMT+01:00 Antoine Pitrou : > > Hello, > > It seems AppVevor builds (and generally Windows builds) have been broken > for some time with a failure in test_distutils: > https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.9471#L2040 > > ====================================================================== > ERROR: test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "C:\projects\cpython\lib\distutils\tests\test_bdist_wininst.py", line 24, in test_get_exe_bytes > exe_file = cmd.get_exe_bytes() > File "C:\projects\cpython\lib\distutils\command\bdist_wininst.py", line 361, in get_exe_bytes > f = open(filename, "rb") > FileNotFoundError: [Errno 2] No such file or directory: 'C:\\projects\\cpython\\lib\\distutils\\command\\wininst-14.12.exe' > ---------------------------------------------------------------------- > > Regards > > Antoine. > _______________________________________________ > 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 zachary.ware+pydev at gmail.com Thu Dec 14 11:36:40 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Thu, 14 Dec 2017 10:36:40 -0600 Subject: [python-committers] AppVeyor builds broken In-Reply-To: References: Message-ID: On Thu, Dec 14, 2017 at 10:27 AM, Antoine Pitrou wrote: > > Hello, > > It seems AppVevor builds (and generally Windows builds) have been broken > for some time with a failure in test_distutils: > https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.9471#L2040 > > ====================================================================== > ERROR: test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "C:\projects\cpython\lib\distutils\tests\test_bdist_wininst.py", line 24, in test_get_exe_bytes > exe_file = cmd.get_exe_bytes() > File "C:\projects\cpython\lib\distutils\command\bdist_wininst.py", line 361, in get_exe_bytes > f = open(filename, "rb") > FileNotFoundError: [Errno 2] No such file or directory: 'C:\\projects\\cpython\\lib\\distutils\\command\\wininst-14.12.exe' > ---------------------------------------------------------------------- See https://bugs.python.org/issue32302. Subsequent builds should succeed; if you need to restart a build on a PR, you have two options. The simpler, noisier option is to close and reopen the PR. Otherwise, log into AppVeyor using GitHub OAuth, which should give you the option to log in as "python". Then navigate to the build you want to restart and click "Re-build PR". -- Zach From victor.stinner at gmail.com Mon Dec 18 06:01:49 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 18 Dec 2017 12:01:49 +0100 Subject: [python-committers] Julien Palard not seen as a core dev on the bug tracker Message-ID: Hi, Julien Palard has been promoted as a core developer at December 8th: https://devguide.python.org/developers/#permissions-history But he is still not seen as a core dev on the bug tracker: https://bugs.python.org/user23063 His nick name is "mdk". Can someone please fix his bpo account? Devguide: https://devguide.python.org/coredev/#issue-tracker Victor From ezio.melotti at gmail.com Mon Dec 18 08:57:16 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Mon, 18 Dec 2017 14:57:16 +0100 Subject: [python-committers] Julien Palard not seen as a core dev on the bug tracker In-Reply-To: References: Message-ID: On Mon, Dec 18, 2017 at 12:01 PM, Victor Stinner wrote: > Hi, > > Julien Palard has been promoted as a core developer at December 8th: > https://devguide.python.org/developers/#permissions-history > > But he is still not seen as a core dev on the bug tracker: > https://bugs.python.org/user23063 > > His nick name is "mdk". Can someone please fix his bpo account? > Done, and welcome to the team Julien! Best Regards, Ezio Melotti > Devguide: https://devguide.python.org/coredev/#issue-tracker > > Victor From victor.stinner at gmail.com Mon Dec 18 09:47:26 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 18 Dec 2017 15:47:26 +0100 Subject: [python-committers] Julien Palard not seen as a core dev on the bug tracker In-Reply-To: References: Message-ID: Oh, Julien told me that he doesn't have the bug triage permission neither. Would you mind to allow him to close bugs as well? :-) Victor 2017-12-18 14:57 GMT+01:00 Ezio Melotti : > On Mon, Dec 18, 2017 at 12:01 PM, Victor Stinner > wrote: >> Hi, >> >> Julien Palard has been promoted as a core developer at December 8th: >> https://devguide.python.org/developers/#permissions-history >> >> But he is still not seen as a core dev on the bug tracker: >> https://bugs.python.org/user23063 >> >> His nick name is "mdk". Can someone please fix his bpo account? >> > > Done, and welcome to the team Julien! > > Best Regards, > Ezio Melotti > >> Devguide: https://devguide.python.org/coredev/#issue-tracker >> >> Victor From ezio.melotti at gmail.com Mon Dec 18 10:14:57 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Mon, 18 Dec 2017 16:14:57 +0100 Subject: [python-committers] Julien Palard not seen as a core dev on the bug tracker In-Reply-To: References: Message-ID: Done as well! On Mon, Dec 18, 2017 at 3:47 PM, Victor Stinner wrote: > Oh, Julien told me that he doesn't have the bug triage permission > neither. Would you mind to allow him to close bugs as well? :-) > > Victor > > 2017-12-18 14:57 GMT+01:00 Ezio Melotti : >> On Mon, Dec 18, 2017 at 12:01 PM, Victor Stinner >> wrote: >>> Hi, >>> >>> Julien Palard has been promoted as a core developer at December 8th: >>> https://devguide.python.org/developers/#permissions-history >>> >>> But he is still not seen as a core dev on the bug tracker: >>> https://bugs.python.org/user23063 >>> >>> His nick name is "mdk". Can someone please fix his bpo account? >>> >> >> Done, and welcome to the team Julien! >> >> Best Regards, >> Ezio Melotti >> >>> Devguide: https://devguide.python.org/coredev/#issue-tracker >>> >>> Victor From nad at python.org Tue Dec 19 03:42:35 2017 From: nad at python.org (Ned Deily) Date: Tue, 19 Dec 2017 03:42:35 -0500 Subject: [python-committers] [RELEASE] Python 3.6.4 is now available Message-ID: <24E5A059-9558-4D15-B846-82A771FEC188@python.org> On behalf of the Python development community and the Python 3.6 release team, I am happy to announce the availability of Python 3.6.4, the fourth maintenance release of Python 3.6. Detailed information about the changes made in 3.6.4 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-4-final Please see "What?s New In Python 3.6" for more information about the new features in Python 3.6: https://docs.python.org/3.6/whatsnew/3.6.html You can download Python 3.6.4 here: https://www.python.org/downloads/release/python-364/ The next maintenance release of Python 3.6 is expected to follow in about 3 months, around the end of 2018-03. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ Enjoy! -- Ned Deily nad at python.org -- [] From victor.stinner at gmail.com Tue Dec 19 09:35:56 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 19 Dec 2017 15:35:56 +0100 Subject: [python-committers] Date of the Python Language Summit? Message-ID: Hi, I'm starting to organize my travel to Cleveland for Pycon US 2018. I would like to know when will be the Python Language Summit to be able to decide how many nights I will stay. The hotel is usually a huge part of the budget. https://us.pycon.org/2018/ May 9,10: Tutorials May 11-13: Talks May 14-17: Sprints My preference would be to skip the two tutorial days, so organize the language summit after the talks. But it is also interesting to have the summit before talks, so we can have more time to discuss proposed ideas... Maybe the best would be the organizee the summut Thursday afternoon (May 10)? Victor From barry at python.org Tue Dec 19 10:58:29 2017 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Dec 2017 10:58:29 -0500 Subject: [python-committers] Date of the Python Language Summit? In-Reply-To: References: Message-ID: <1960BDFA-F397-4B82-B635-EEE38257A6D6@python.org> On Dec 19, 2017, at 09:35, Victor Stinner wrote: > > I'm starting to organize my travel to Cleveland for Pycon US 2018. I > would like to know when will be the Python Language Summit to be able > to decide how many nights I will stay. The hotel is usually a huge > part of the budget. Traditionally, we?ve held the summit on the first day of tutorials. Larry and I haven?t started planning 2018?s, but I expect the tradition to hold. -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 antoine at python.org Sun Dec 31 15:37:15 2017 From: antoine at python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 21:37:15 +0100 Subject: [python-committers] Travis-CI breakdown Message-ID: <75dd4dd4-ac38-ce11-74e1-ae4c1ab4c4bb@python.org> Hi, Do we have a contact over at Travis-CI? Their Linux build infrastructure has become crazily slow lately, something is clearly going wrong. Regards Antoine.