[python-committers] No Travis-CI on OS X?

Hi, Perhaps it would be possible to set up a Travis CI matrix entry for OS X, those builds are often quite slow but at least it could be part of the "allowed failures" suite. That would help detect platform issues at PR time rather than later :-) Regards Antoine. __

Re: [python-committers] No Travis-CI on OS X?

onald Stufft a écrit : > > >> On May 2, 2017, at 5:35 PM, Antoine Pitrou > <mailto:[email protected]>> wrote: >> >> >> Hi, >> >> Perhaps it would be possible to set up a Travis CI matrix entry for OS >> X, those builds are often qui

Re: [python-committers] Github reviews are cannibalizing BPO

Le 03/05/2017 à 10:06, Nick Coghlan a écrit : > On 3 May 2017 at 05:09, M.-A. Lemburg wrote: >> This doesn't have much to do with UX/UI. It's mainly a questions >> of culture. > > It's about the UI/UX for me, as Roundup is missing a few modern > collaboration features: > > 1. Easy user mentions

[python-committers] Coverage build broken?

Hello, I'm getting the following error on the Travis-CI coverage job: (from https://travis-ci.org/python/cpython/jobs/228758363#L837 ) Collecting coverage Downloading coverage-4.3.4.tar.gz (361kB) Complete output from command python setup.py egg_info: running egg_info creating pip

[python-committers] Guide to pushing to submitters' repo?

Hi, We now have a functionality to allow core developers to push to PR repositories, but I can't find out how to make it work. For example I have: $ git remote -v gescheitgit://github.com/gescheit/cpython.git (fetch) gescheitgit://github.com/gescheit/cpython.git (push) origin h

Re: [python-committers] Guide to pushing to submitters' repo?

Le 25/05/2017 à 15:06, Nick Coghlan a écrit : > On 25 May 2017 at 18:01, Antoine Pitrou wrote: >> Did someone manage to make this work? Can they post the entire >> instructions they used? (including local branch setup) > > The minimal set of instructions some of us work

Re: [python-committers] Guide to pushing to submitters' repo?

Le 25/05/2017 à 16:05, Zachary Ware a écrit : > > Unfortunately, GitHub does not allow pushing back to refs/pull/*. To > get it to set you up to push back to the contributor's repo, you'd > need to provide the contributor's name and branch name, which is much > less convenient if you're just loo

Re: [python-committers] Guide to pushing to submitters' repo?

Le 25/05/2017 à 17:52, Carol Willing a écrit : >> >> Thanks for the pointer. Unfortunately, it seems that it really wants to >> authenticate using username and password (even though browsing a public >> project): >> >> $ hub checkout https://github.com/python/cpython/pull/1785 >> github.com usern

Re: [python-committers] Please stop fixing easy issues right now! Leave them as exercices to newcomes

Hi, Le 02/06/2017 à 11:23, Victor Stinner a écrit : > > *Many* people ask me regulary "how to find easy Python issues", and > the last 3 years, I always failed to find such issues... Many "easy > issues" are older than 3 years old, have more than 20 comments and no > compromise has been found ho

Re: [python-committers] I have blocked Wes Turner from the Python org on GitHub

How did he react to the whole thing? Did he give signs of wanting to improve his behaviour? Regards Antoine. Le 02/06/2017 à 18:47, Brett Cannon a écrit : > I just wanted to quickly let people know I lifted Wes' two-month ban and > emailed him to notify him of the lifting. > > On Fri, 31 Mar

[python-committers] Sporadic failures in test_multiprocessing_main_handling?

Hello all, Are we aware of sporadic failures in test_multiprocessing_main_handling? I got a hang here and I'm wondering if it's due to my changes: https://travis-ci.org/python/cpython/jobs/242108490#L2211 Thanks & Regards Antoine. ___ python-committer

Re: [python-committers] Sporadic failures in test_multiprocessing_main_handling?

I manage to reproduce. Sorry for the noise here. Regards Antoine. Le 12/06/2017 à 19:50, Antoine Pitrou a écrit : > > Hello all, > > Are we aware of sporadic failures in test_multiprocessing_main_handling? > I got a hang here and I'm wondering if it's due to my

[python-committers] How does GitHub count contributors?

Hello, This is a bit of a futile question, but I realize I'm nowhere to be seen in https://github.com/python/cpython/graphs/contributors Is there some map file somewhere that I must update to match my commit e-mail to my GitHub account? Regards Antoine.

Re: [python-committers] How does GitHub count contributors?

Le 24/06/2017 à 18:05, Terry Reedy a écrit : > > I use the same > email for both github and bpo. I can't see if your github email is the > same as your primary bpo email and I don't know if that makes any > difference. I added a secondary e-mail to my GitHub account (matching the e-mail I us

Re: [python-committers] macOS Travis CI job became mandatory?

Le 26/06/2017 à 16:46, Victor Stinner a écrit : > 48 minutes later: the macOS is running for 33 minutes, but Travis CI > fails to retrieve the logs :-/ > https://travis-ci.org/python/cpython/jobs/247090627 Just kill the job :-) ___ python-committers ma

Re: [python-committers] macOS Travis CI job became mandatory?

Le 26/06/2017 à 17:22, Victor Stinner a écrit : > End of the funny story: the macOS job was killed by Travis CI: > "The job exceeded the maximum time limit for jobs, and has been terminated." > > Thanks to that, the whole Travis CI job on the PR became green... > > I would suggest to remove the

Re: [python-committers] macOS Travis CI job became mandatory?

Le 26/06/2017 à 15:57, Victor Stinner a écrit : > Hi, > > I was waiting for the result of Travis CI: 3 jobs already completed, > but the macOS job was still running. The macOS job is marked as > "allowed failure". I cancelled the job, but then the Travis CI was > marked as failed in the PR :-/ So

[python-committers] AppVeyor off?

Hi, Is AppVeyor turned off these days? I don't see a build on https://github.com/python/cpython/pull/2417 Regards Antoine. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code

Re: [python-committers] AppVeyor off?

Nevermind, it seems to have come back online. Le 17/07/2017 à 12:25, Antoine Pitrou a écrit : > > Hi, > > Is AppVeyor turned off these days? I don't see a build on > https://github.com/python/cpython/pull/2417 >

[python-committers] CLA bot bug for a particular contributor

Hi, How can I get the CLA bot to fix its knowledge for a particular contributor? bugs.python.org user Gareth Rees (https://bugs.python.org/user14554) has signed the CLA and filled in his GitHub username "gareth-rees". However, a PR filed by Gareth (https://github.com/python/cpython/pull/2741) h

Re: [python-committers] "trivial" label replaced with "skip issue"

Le 17/07/2017 à 22:16, Brett Cannon a écrit : > > > On Sun, 16 Jul 2017 at 15:22 Victor Stinner > wrote: > > 2017-07-16 16:10 GMT+02:00 Victor Stinner >: > > What is the benefit of converting old Misc/NEWS entries?

Re: [python-committers] My (positive) feedback on the new CPython workflow

Le 18/07/2017 à 13:36, Serhiy Storchaka a écrit : > > I have a different impression. Some core developers (like Raymond or > Martin) stopped committing even if they are active on the bug tracker or > mailing lists. Others make much less commits than they did before the > migration. Assuming y

[python-committers] Unreliable contributor stats

Le 18/07/2017 à 12:24, Victor Stinner a écrit : > > == More contributors, more contributions, faster reviewed/merged == > > In term of contributions, I looked at statistics yesterday and it > became clear the number of different authors is significantely much > higher, around 25 contributors / m

[python-committers] "Invalid symmetric difference expression" on Travis-CI

Hi, I've just got this weird error on Travis-CI (the build itself is still marked green, which is great :-D): https://travis-ci.org/python/cpython/jobs/254906991 """ $ set -e if ! git diff --name-only $TRAVIS_COMMIT_RANGE | grep -qvE '(\.rst$)|(^Doc)|(^Misc)' then echo "Only docs were up

[python-committers] How do I kill an AppVeyor build?

Hi, It seems only some select people have the ability to kill or re-launch AppVeyor builds? Regards Antoine. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: ht

[python-committers] Travis-CI compiles twice

Hi, I've noticed that Travis-CI (sometimes?) compiles CPython twice. Example in https://travis-ci.org/python/cpython/jobs/256552880 First compilation in the "./configure && make" step: https://travis-ci.org/python/cpython/jobs/256552880#L1103 Second compilation in "make buildbottest" step: http

Re: [python-committers] Travis-CI compiles twice

Le 24/07/2017 à 10:55, Victor Stinner a écrit : > IMHO everything is fine and we don't have to do anything ;-) What do you mean? The fact that all the CPython source code (including C extensions) is compiled twice looks suboptimal to me. We could probably win a minute or two on Travis-CI build

[python-committers] AppVeyor failure on test_asyncgen?

Hello, One of my PR builds got an AppVeyor failure in test_asyncgen and I really doubt it is due to the PR itself: https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.5366#L682 == FAIL: test_async_gen_asyncio_gc_aclose_

Re: [python-committers] Travis CI: macOS is now blocking -- remove macOS from Travis CI?

Le 01/09/2017 à 19:15, Victor Stinner a écrit : > > Yesterday, it was possible to merge a PR even if the macOS job was > still queued (no started). It's still possible today. > Maybe we should remove the pre-commit macOS task from the Travis CI > config to focus on post-commit macOS buildbots?

Re: [python-committers] What is a CPython core developer?

Hi Victor, Thank you, this is a useful write-up! Le 22/09/2017 à 16:26, Victor Stinner a écrit : > > I started to list "responsabilities" (is it the correct word?) of a > core developer. > > First of all, I like how Mariatta summarized a promotion (in an oral > discussion that we had). Becomin

Re: [python-committers] Travis CI: macOS is now blocking -- remove macOS from Travis CI?

For the record: https://blog.travis-ci.com/2017-09-22-macos-update Regards Antoine. Le 01/09/2017 à 19:15, Victor Stinner a écrit : > Hi, > > Since today, it seems like the macOS task of a Travis CI job to > validate a pull request hangs the whole job. > > Don't try to cancel the macOS job,

Re: [python-committers] Hacktoberfest

Le 28/09/2017 à 18:58, Stefan Krah a écrit : > On Thu, Sep 28, 2017 at 09:21:04AM -0700, Mariatta Wijaya wrote: >> October is hacktoberfest (https://hacktoberfest.digitalocean.com/) >> In the month of October, people can sign up and contribute to open source >> projects on GitHub. If they make 4 P

[python-committers] Merging a PR with failed CI

Hello, What is the recommended way of merging a PR when Travis-CI failed for unrelated reasons? (apparently an external NNTP server is having hiccups) See https://github.com/python/cpython/pull/4065 Regards Antoine. ___ python-committers mailing list

Re: [python-committers] Reminder: 12 weeks to 3.7 feature code cutoff

On Wed, 1 Nov 2017 17:47:45 -0400 Ned Deily wrote: > If you have something in the pipeline, please either let me know or, when > implemented, add the feature to PEP 537, the 3.7 Release Schedule PEP. I hope to be able to write the implementation for PEP 556. https://www.python.org/dev/peps/pep-

Re: [python-committers] Enabling depreciation warnings feature code cutoff

Perhaps this discussion can go back to python-dev? Le 06/11/2017 à 20:25, Neil Schemenauer a écrit : > On 2017-11-06, R. David Murray wrote: >> I'm curious which ones you are seeing it in? It could be we are >> operating in different problem spaces :) > > In the last few months: Pillow, docut

[python-committers] IPv6 issues on *.python.org

Hello, I'm having IPv6 issues on *.python.org. Is anyone having the same issues or is it just me? Who should I report this to? $ curl -6 -v -I https://www.python.org/ * Trying 2a04:4e42:9::223... * Connected to www.python.org (2a04:4e42:9::223) port 443 (#0) * found 148 certificates in /etc/

Re: [python-committers] IPv6 issues on *.python.org

Le 16/11/2017 à 15:26, Victor Stinner a écrit : > Hi, > >> * gnutls_handshake() failed: Error in the pull function. > > It looks more like a TLS issue rather than an IPv6 issue. It reminds > me a similar TLS issue on blog.python.org: > > "blog.python.org in HTTPS doesn't provide a server certi

[python-committers] CLA indication on Github out of date?

Hello, I forget... Who handles updating the Python CLA database? One of our contributors apparently signed the CLA but still has the "CLA not signed" indicator on their PR: https://github.com/python/cpython/pull/4496#issuecomment-346792634 (sent to: python-committers, board@psf) Regards Antoin

Re: [python-committers] Requirements to get the "bug triage" permission?

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 be

Re: [python-committers] Requirements to get the "bug triage" permission?

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 tho

Re: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity

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 eas

Re: [python-committers] RFC: Process to become a core developer

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 promot

Re: [python-committers] RFC: Process to become a core developer

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-mentors

Re: [python-committers] Number of contributors

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

Re: [python-committers] RFC: Process to become a core developer

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. >&g

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

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://bug

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

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.

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

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

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

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

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

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

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

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 p

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

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

[python-committers] AppVeyor builds broken

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

[python-committers] Travis-CI breakdown

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. ___ python-committers mailing list [email protected] https://mail.python.org/ma

Re: [python-committers] Travis-CI breakdown

e CI came forward on the core-workflow mailing > list asking if we were willing to switch, but I didn't hear back after > saying what we would probably need to make the switch. > > On Sun, Dec 31, 2017, 12:37 Antoine Pitrou, <mailto:[email protected]>> wrote: > > >

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

Hi, So, for the record (even though this discussion has petered out), I've just bought a U2F key and it doesn't work on Ubuntu Firefox (though it works on Chromium). So it's pretty much unusable for me. Regards Antoine. ___ python-committers mailing

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

Le 06/01/2018 à 20:00, Alex Gaynor a écrit : > Hey Antoine, > > Assuming you're on Firefox57, it requires a pref -- once the WebAuthn > spec is finalized we'll drop the pref > -- https://mobile.twitter.com/jamespugjones/status/91231495223226 Yes, I already did so... I'm using https://demo.y

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

Le 06/01/2018 à 20:04, Antoine Pitrou a écrit : > > I have AppArmor enabled on Firefox, I may try to disable it. ... Nothing changed unfortunately. Regards Antoine. ___ python-committers mailing list [email protected]

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

It turns out that is a bug with Ubuntu's package for Firefox. It works fine with the upstream build... :-( https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1741768 Regards Antoine. Le 06/01/2018 à 20:42, Barry Warsaw a écrit : > On Jan 6, 2018, at 14:00, Alex Gaynor wrote: >> >> Hey A

Re: [python-committers] AppVeyor is now required to pass on PRs

Hi Brett, Stability doesn't appear to be a problem, but we have much less parallelism on AppVeyor than we do on Travis-CI. This may make waiting times longer than they used to be. Apparently 3.6 builds (and perhaps 2.7) trigger two sequential AppVeyor jobs: https://ci.appveyor.com/project/pytho

Re: [python-committers] Official way to check out a tag?

Le 23/01/2018 à 11:28, Stefan Krah a écrit : > > Hello, > > what is the official way to checkout a tag for debugging? I did: > >git checkout v3.6.0 > > > This just worked in mercurial, but doing the above results in a > compile error: > >threadmodule.c:1355: multiple definition of `

Re: [python-committers] Let's give commit privileges to Nathaniel J. Smith

+1 from me as well. Le 25/01/2018 à 00:23, Yury Selivanov a écrit : > Hi, > > I want to propose granting commit privileges to Nathaniel J. Smith. > He's interested in the idea of becoming a core developer, and given > the quality of his contributionsI think he won't need any extensive > mentori

Re: [python-committers] Welcoming Petr Viktorin as our newest core developer :)

Le 23/04/2018 à 16:39, Nick Coghlan a écrit : > Hi folks, > > With my recent proposal to accept Petr Viktorin as a specialist core > developer focusing on extension module imports receiving several +1's > and no concerns being raised, I'm happy to report that Brett has now > granted Petr his addi

Re: [python-committers] How to calm down the discussion on the PEP 572?

Obviously, the issue is less the number of messages per month than the fact that most of them are about a single proposal :-) Regards Antoine. Le 26/04/2018 à 17:10, Victor Stinner a écrit : > I computed stats since January 2017: > > 2017-01: Total: 220 msg; avg: 7.6 msg/day; max: 20 msg at 2

Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?

-1: dislike Regards Antoine. Le 02/05/2018 à 11:49, Victor Stinner a écrit : > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > >https://www.python.org/dev/pe

Re: [python-committers] Proposing Mark Shannon to be a core developer

+1. Regards Antoine. Le 14/05/2018 à 22:41, Larry Hastings a écrit : > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, > writing both the PEP and the implementation.  This shipped in Python 3.3 > and was listed as one of the top features of that release as according

Re: [python-committers] Visual Studio Team Services checks on pullrequests

Le 17/05/2018 à 16:07, Steve Dower a écrit : > Okay, now that it's morning and I have coffee, here's a full update on > what I've been doing (those at the language summit have heard some of > this already). > > Visual Studio Team Services is Microsoft's integrated code/build/release > infrastruct

Re: [python-committers] A different way to focus discussions

Hi, Note that some PEPs are, still, mostly uncontroversial (PEP 574 is an example). I agree with Nathaniel : PEP 572 is the poster child for lengthy, heated discussions. I'm still surprised you thought it was a good idea to discuss this. Perhaps it we tried to discourage syntax change and/or b

Re: [python-committers] Comments on moving issues to GitHub

Le 19/05/2018 à 02:10, Victor Stinner a écrit : > Hi, > > I failed to get the microphone after Mariatta's secret talk about > moving Python issues from bugs.python.org (Roundup) to GitHub. A "secret talk"? What is that? > I don't have a strong opinion about moving issues to GitHub. If that's o

Re: [python-committers] A different way to focus discussions

Le 22/05/2018 à 20:58, Barry Warsaw a écrit : > >> Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > I don't know whether this will help focus rambling PEP discussions. I > personally don't love the linearity of GH comments. Threading is useful! What has become of the

Re: [python-committers] A different way to focus discussions

Le 22/05/2018 à 22:06, Brett Cannon a écrit : > > > On Tue, 22 May 2018 at 12:07 Antoine Pitrou <mailto:[email protected]>> wrote: > > > Le 22/05/2018 à 20:58, Barry Warsaw a écrit : > > > >> Thoughts? (We can dogfood this proposal too,

Re: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

Also there's https://bugs.python.org/issue33612 which appears quite critical. Regards Antoine. Le 23/05/2018 à 13:45, Serhiy Storchaka a écrit : > 15.05.18 14:51, Ned Deily пише: >> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your >> feature fixes, bug fixes, and documentat

Re: [python-committers] A different way to focus discussions

Le 24/05/2018 à 18:54, Brett Cannon a écrit : > > I don't think Zulip works for structured discussion.  I also find it > slightly less usable than I expected. > > Why specifically? Do you still find IRC more usable? Um, no. But I find Zulip's way of grouping discussions by day *then* b

Re: [python-committers] A different way to focus discussions

Le 24/05/2018 à 20:02, Brett Cannon a écrit : > > Just trying to > > understand how Discourse would be different enough to solve the issue > > you're having. > > Which issue exactly?  Zulip is decent as a chat system.  It wouldn't > really work for PEP discussions, IMO.  That'

Re: [python-committers] Comments on moving issues to GitHub

Hi Mariatta, Le 02/06/2018 à 01:07, Mariatta Wijaya a écrit : > > For those who missed it, some resources: > > 1. My language summit slides > (https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-presentation) > There are 3 bonus slides at the end which I did not get to cover,

Re: [python-committers] number of active core devs

That's not the symptom of a « 50% reduction in activity ». 10 years ago, it was already the case that many core developers were inactive (not necessarily the same as today!). That said, it is true that core development activity continues to shrink, at least according to this particular metric: h

Re: [python-committers] number of active core devs

Le 03/06/2018 à 12:36, Berker Peksağ a écrit : > On Sun, Jun 3, 2018 at 11:27 AM, Antoine Pitrou wrote: >> That said, it is true that core development activity continues to >> shrink, at least according to this particular metric: >> https://github.com/python/cpython/graph

Re: [python-committers] Vote to promote Pablo Salingo Salgado as core developer

Le 14/06/2018 à 04:30, Terry Reedy a écrit : > On 6/13/2018 7:03 PM, Carol Willing wrote: >> +1 With Victor's mentoring (1 or 2 months), I believe that it is >> reasonable to promote Pablo to a core developer either now or after 3 >> months of coaching. >> >> I would also like to see Cheryl Sabe

Re: [python-committers] Vote to promote Pablo Salingo Salgado as core developer

Le 14/06/2018 à 19:25, Gregory P. Smith a écrit : > Quick response: > > +0.5 > > But Pablo shows drive and desire to do good things and an > ability to eventually do it even if there are learning bumps along the > way. This is my impression as well, having interacted with Pablo on a single PR o

Re: [python-committers] Vote to promote Pablo Salingo Salgado as core developer

Thanks for correcting me. (by the way I'm 8th in that list... Serhiy is 2nd, not me ;-)) Regards Antoine. Le 18/06/2018 à 20:37, Brett Cannon a écrit : > > > On Mon, 18 Jun 2018 at 11:17 Antoine Pitrou <mailto:[email protected]>> wrote: > > > Le 1

Re: [python-committers] Maintenance Tasks

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

Re: [python-committers] Changing commiter status

Le 19/06/2018 à 22:26, Ethan Furman a écrit : > On 06/19/2018 11:14 AM, M.-A. Lemburg wrote: > >> Ok, let me be even clearer :-) >> >> While I understand that there is a need to show the world that >> we need more active core devs, this drive to shelve existing >> developers is not a good way to

Re: [python-committers] A different way to focus discussions

Le 28/06/2018 à 13:04, Victor Stinner a écrit : > It seems like the PEP 572 discussions restarted on python-dev mailing > list with more than 100 emails in one week. > > Stupid idea: we created a mailing list just to fix os.random(): PEP > 522 and PEP 524, whereas these discussions were not the o

Re: [python-committers] Time for 3.4.9 and 3.5.6

OTOH, we're talking about a doc fix for a very old version. Surely people who rely on the documented opcodes there have already fixed their software to deal with the discrepancy. Regards Antoine. Le 08/07/2018 à 18:44, Serhiy Storchaka a écrit : > 08.07.18 13:02, Larry Hastings пише: >> On 07

Re: [python-committers] Transfer of power

I think it would be worth studying the governance structure (*) of a bunch of open source projects picked according to a set of criteria: - major project in # of users and contributors - non BDFL-governed - mostly volunteer-driven - with an established decision process for major enhancements (*)

Re: [python-committers] Transfer of power

I'd like to point out that the N-virate idea doesn't handle a key issue: once you have a N-virate, how do you evolve its composition according to the implication and motivation of its members - but also to remarks or frustation by non-virate contributors (especially new contributors who will feel

Re: [python-committers] Transfer of power

Le 12/07/2018 à 19:55, Brett Cannon a écrit : > > One other idea if we go the BDFL or triumvirate route is we could ask > Guido to choose (if he's willing). I think Guido's key point is he wants > us to choose how we want to keep this team going, but that may not > preclude us to essentially nami

Re: [python-committers] Transfer of power

Le 12/07/2018 à 20:22, Doug Hellmann a écrit : > Excerpts from Brett Cannon's message of 2018-07-12 11:11:49 -0700: >> On Thu, 12 Jul 2018 at 11:02 Yury Selivanov wrote: >> >>> >>> IOW I don't see anyone (or some group of 3) who is as well-versed in >>> everything on Guido's level. That can be s

Re: [python-committers] Transfer of power

Le 12/07/2018 à 21:17, Doug Hellmann a écrit : > > If the primary approach to decision making is to delegate unless > an arbiter is absolutely necessary, then long-term consistency and > stability comes less from finding individuals to commit to serving > for very long terms on the N-virate as it

Re: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power)

Le 13/07/2018 à 13:31, Nathaniel Smith a écrit : > > I volunteer to co-author such a PEP. But I'm not up to doing it on my > own. So... who else wants to be a co-author? (I'm not going to > pressure anyone, but Brett, Mariatta, and Carol, please know that your > names were the first ones that jum

Re: [python-committers] Identify roles of the BDFL

Le 13/07/2018 à 18:36, Victor Stinner a écrit : > > Let me elaborate this part. One quality of the BDFL (Guido) is to take > unpopular decision when he knows that it is the right choice. > > Some examples: > > * PEP 572: assignment expressions. > > * The PEP 446 "Make newly created file descri

Re: [python-committers] Transfer of power

Le 16/07/2018 à 04:38, Tim Peters a écrit : > > But I'm not sure it's fully appreciated just how active Guido has been > in those at times.  The "accepted/rejected" at the end of major PEPs is > just a small part of that.  Along the way, e.g., it's been pretty common > to see a "Save your breath.

Re: [python-committers] Transfer of power

Le 16/07/2018 à 20:05, Tim Peters a écrit : > [Tim] > > > But I'm not sure it's fully appreciated just how active Guido has been > > in those at times.  The "accepted/rejected" at the end of major > PEPs is > > just a small part of that.  Along the way, e.g., it's been pretty >

Re: [python-committers] Transfer of power

Le 17/07/2018 à 04:07, Brett Cannon a écrit : > > This ties into the core dev sponsor idea that got floated where all > inexperienced PEP authors need someone to sign up to shepherd them > through the process. That way everything is more structured and, with > this idea, also more uniform. This

Re: [python-committers] An alternative governance model

Hi Barry, Le 18/07/2018 à 04:02, Barry Warsaw a écrit : > > A singular BDFL provides clear leadership. With a council of elders, it will > be more difficult to communicate both to the Python community, and to the > larger, more peripheral user base, that any particular individual has the > a

Re: [python-committers] An alternative governance model

Hi Ethan, Le 18/07/2018 à 11:49, Ethan Furman a écrit : >> >> You're creating a huge problem here. Whatever dictator you come up >> with, not everyone will be ok with that choice. What are they supposed >> to do? If one doesn't think X is legitimate as a dictator, how does one >> keep contribu

Re: [python-committers] An alternative governance model

Le 18/07/2018 à 17:58, Ethan Furman a écrit : > > If we, by majority vote, pick a governance model (dictator, council, or > whatever), then that legitimizes it. If we, by > majority vote, pick the new BDFL, then that legitimizes it. Being unhappy > with the choice does not make the choice >

Re: [python-committers] An alternative governance model

Le 18/07/2018 à 18:36, Łukasz Langa a écrit : > >> On Jul 18, 2018, at 10:58 AM, Ethan Furman wrote: >> >> If we, by majority vote, pick a governance model (dictator, council, or >> whatever), then that legitimizes it. If we, by majority vote, pick the new >> BDFL, then that legitimizes it.

[python-committers] An alternative governance model

Le 18/07/2018 à 19:51, Barry Warsaw a écrit : > On Jul 18, 2018, at 01:43, Antoine Pitrou wrote: >> >> Why do you think non-BDFL projects have a problem with """ambiguity as >> to the authority of said decision"""? What is your basis for th

Re: [python-committers] Language moratorium

Le 18/07/2018 à 20:47, Barry Warsaw a écrit : > On Jul 18, 2018, at 09:11, Stefan Krah wrote: > >> if I remember correctly, we had a moratorium for language changes around >> versions 3.2-3.3. I think during that time relatively few BDFL-level >> decisions were required. >> >> Perhaps we could

  1   2   3   4   5   6   >