Re: [python-committers] Github reviews are cannibalizing BPO
On 2 May 2017 at 20:42, Donald Stufft wrote: > > On May 2, 2017, at 3:09 PM, M.-A. Lemburg wrote: > >> This doesn't have much to do with UX/UI. It's mainly a questions >> of culture. Github is more geared up for a culture of quick chat >> style comments, whereas bpo has traditionally seen a more elaborate >> in-depth discussions style. > > This is not really accurate to my experience using GitHub. In pip for > example while we have distutils-sig and a pypa-dev mailing list we hardly > ever use them for pip focused discussion. The vast bulk of our discussion > (including quite long ones, and I think most folks who end up in a > discussion with me know I can produce a fair amount of content in one) occur > entirely within GitHub and it works just fine. I don’t think this is unique > to pip either. Pretty much the only time we use anything but GitHub are when > the blast radius for a change is larger then pip itself (e.g. something that > touches pip, setuptools, and pypi) which we use distutils-sig for, or when > something is just a notice that doesn’t require discussion, which we use > pypa-dev for. > > I agree that there are benefits to separating code review and issue tracking > (although I’m not a purist about it, I think some PRs are too small to > warrant an issue for instance) and I think that without some effort to > automate and write a bot GitHub issues are not a good fit for replacing bpo. > However I think it’s going to be a regular struggle to get people to try and > primarily use bpo for issue discussion (vs code review) because the friction > of doing so is fairly high. I think if you want to encourage people to > utilize bpo better, your best bet is to do everything you can to reduce that > friction. I have to agree here. I'm not sufficiently involved in bpo discussions to have a strong opinion, but my experience with pip is the same as Donald's - it's pretty easy to have complex design decisions on github, as well as having review style comments. I'd have to say the new "create a review" interface in github can make conversations harder to follow, particularly if you're reading the emails rather than reading on the github site itself, but I tend to work by reading emails to spot the interesting topics, then go to GH for the full story. One other huge win for me with github over bpo is that the former allows formatted text. I find having to read plaintext discussions on bpo *much* more tiring than reading github formatted content. But the big problem for me with github discussions in Python is the sheer volume. My normal github workflow (which works fine for pip) collapses under the volume of Python traffic. That's not to say that bpo is any better - I basically ignore the majority of bpo traffic that I['m not automatically nosied on, for exactly the same reason, that my approach doesn't scale. To summarise: 1. The traffic for CPython is the biggest issue - expecting people with established workflows that cope with it to rework those workflows to work with gh rather than bpo is a big ask. 2. Having formatted text for the discussions is (IMO) a huge win. 3. Apart from familiarity, I don't think there's much difference in the ability to have design discussions (as long as you don't hide design comments in the GH review notes, of course, but that's just a matter of using the tool correctly). 4. Neither interface (in my experience) does a wonderful job of making the discussion transparent via email. But I tend to see email as a transient notification medium - we should probably concentrate more on the UX when interacting with the website directly. I can't really weight these factors, so I'll leave that to the people who interact with the trackers more often than I do. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Github reviews are cannibalizing BPO
On 3 May 2017 at 09:18, Antoine Pitrou wrote: > > As for "native" +1 mentions in Github, I tend to find them unhelpful, as > I don't know why people say "+1" at all. So I usually ignore them. The point is that it's easier to ignore +1s in github, because they don't trigger notification emails, and they don't add an extra conversation element :-) On bpo, +1's are indistinguishable (except for content) from substantive comments. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Github reviews are cannibalizing BPO
On 3 May 2017 at 10:30, M.-A. Lemburg wrote: > I don't think we should open a discussion of whether to move away > from bpo or not. Agreed... > The thread topic only refers to how we deal with > discussions which should be had on bpo rather than Github PRs > and I think we mostly agree that having them on bpo is better, > regardless of how we view Github discussions in general. I don't agree, but as you said above, that's not the topic of this thread. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposing Carol Willing to become a core developer
On 23 May 2017 at 19:15, Brett Cannon wrote: > While at the PyCon US sprints the idea came up of offering Carol Willing > developer privileges. Everyone at the table -- about 6 of us -- liked the > idea and Carol also said she would happy to become a core dev, so I'm > officially putting her forward for consideration. > > For those of you who don't know Carol, she basically knows our developer > workflow better than most of us. :) ; she's very active on the devguide and > core-mentorship. Carol has also attended the PyCon US language summit two > years in a row as a representative for the Jupyter project. She is actually > so good with new people that she managed to get my wife to make her first > open source contribution (something I never managed to do). > > As usual, if you support/object to this idea, please say so. :) Definitely +1 from me. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] How do I kill an AppVeyor build?
You need to log on as the Appveyor account in order to manage builds. It's possible to link a Github team with an Appveyor admin role to allow the team to all have the ability to (effectively) log in as the appveyor account. It's a bit fiddly to set up (and use :-() but it does work. If whoever currently owns the cpython appveyor account wants help setting things up, I've done it for pip so I can assist. Paul On 18 July 2017 at 17:20, Antoine Pitrou wrote: > > Hi, > > It seems only some select people have the ability to kill or re-launch > AppVeyor builds? > > Regards > > Antoine. > ___ > python-committers mailing list > python-committers@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] How do I kill an AppVeyor build?
I'll get something for you, but it may not be for a couple of days. Paul On 18 July 2017 at 18:23, Brett Cannon wrote: > I set up the account and Zach has access. If you have instructions to point > me at, Paul, I can see if I can set it up. > > > On Tue, 18 Jul 2017 at 09:26 Paul Moore wrote: >> >> You need to log on as the Appveyor account in order to manage builds. >> It's possible to link a Github team with an Appveyor admin role to >> allow the team to all have the ability to (effectively) log in as the >> appveyor account. It's a bit fiddly to set up (and use :-() but it >> does work. If whoever currently owns the cpython appveyor account >> wants help setting things up, I've done it for pip so I can assist. >> >> Paul >> >> On 18 July 2017 at 17:20, Antoine Pitrou wrote: >> > >> > Hi, >> > >> > It seems only some select people have the ability to kill or re-launch >> > AppVeyor builds? >> > >> > Regards >> > >> > Antoine. >> > ___ >> > python-committers mailing list >> > python-committers@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@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] How do I kill an AppVeyor build?
That's the one. If you select the github team you want (for PyPA I set up an "Appveyor Admins" team) and choose the Administrator role. That may well be all you need to do - I don't recall if you need to do anything on the github side. Once you do that, people in the relevant github group, when logging into Appveyor with github will get a message "Specified user belongs to multiple accounts" and the "Account" dropdown will contain their own account and "python". They need to select "python" to get the option to manage (cancel or restart) builds. One reason we might want to restrict access is that logging in like this gives the user full access to the Appveyor account, including (as far as I can tell) the ability to grant further privileges. It's possible to create additional roles, but I don't see a "Cancel and restart builds" privilege. I think that's all that's needed - give me a shout if I've missed anything. Paul On 18 July 2017 at 19:07, Zachary Ware wrote: > On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon wrote: >> I set up the account and Zach has access. If you have instructions to point >> me at, Paul, I can see if I can set it up. > > Looks like https://ci.appveyor.com/gitHubTeams while logged in as 'python'. > > That looks like the right place to make the changes, anyway; I haven't > tried to actually make any :) > > -- > Zach > ___ > python-committers mailing list > python-committers@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] How do I kill an AppVeyor build?
BTW, the docs for all this are at https://www.appveyor.com/docs/team-setup/#github-integration although I found them a bit hard to follow, personally. Paul On 18 July 2017 at 19:15, Paul Moore wrote: > That's the one. If you select the github team you want (for PyPA I set > up an "Appveyor Admins" team) and choose the Administrator role. That > may well be all you need to do - I don't recall if you need to do > anything on the github side. > > Once you do that, people in the relevant github group, when logging > into Appveyor with github will get a message "Specified user belongs > to multiple accounts" and the "Account" dropdown will contain their > own account and "python". They need to select "python" to get the > option to manage (cancel or restart) builds. > > One reason we might want to restrict access is that logging in like > this gives the user full access to the Appveyor account, including (as > far as I can tell) the ability to grant further privileges. It's > possible to create additional roles, but I don't see a "Cancel and > restart builds" privilege. > > I think that's all that's needed - give me a shout if I've missed anything. > Paul > > > On 18 July 2017 at 19:07, Zachary Ware wrote: >> On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon wrote: >>> I set up the account and Zach has access. If you have instructions to point >>> me at, Paul, I can see if I can set it up. >> >> Looks like https://ci.appveyor.com/gitHubTeams while logged in as 'python'. >> >> That looks like the right place to make the changes, anyway; I haven't >> tried to actually make any :) >> >> -- >> Zach >> ___ >> python-committers mailing list >> python-committers@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] How do I kill an AppVeyor build?
On 18 July 2017 at 20:59, Brett Cannon wrote: > I went ahead and clicked buttons. :) I set Python core as users and release > managers as admins (on top of Zach and me already being admins). Cool - when I log in now I have "python" as an option. I can't restart a build, but that's as expected - as admins, only RMs will be able to restart or cancel builds. It might be that adding the privilege "Projects -> Run Project Builds" (either to the "Users" role or to a specific new role linked with the core dev GH group) would give the ability to restart/cancel builds. But I haven't tested that. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] New workflow - some questions
I'm just looking at doing some work for the first time under the new workflow. Most things look fine - I'm familiar with git/github, so there's nothing startling in there, but I do have a few small questions: 1. Section 32.2 in the Git bootcamp section - is there any reason to use git@github URLs for the clones? I normally always use https://github.com URLs, as they work with my proxy at work. 2. Section 32.10, I generally use "Compare and create pull request" from my clone's github page, as that seems simpler. Is there any reason for starting from the cpython repo - the process working that way (which I wasn't even aware of!) seems more complex. I can't see that it matters much, but I wouldn't want to mess up a PR if there *is* a difference in the results. 3. The new blurb tool - I presume I'll need to set that up somewhere/somehow, and use it to create a news entry. But I can't find any docs on it at all :-( There may be other stuff - I've been watching the core-workflow list, and it feels like there's some awfully complex stuff being discussed. But so far it looks pretty straightforward and "as expected" - which is a credit to Brett and the others who've set all this up! Thanks, Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] New workflow - some questions
On 28 July 2017 at 23:30, Mariatta Wijaya wrote: >> 1. Section 32.2 in the Git bootcamp section - is there any reason to >> use git@github URLs for the clones? I normally always use >> https://github.com URLs, as they work with my proxy at work. > > > I don't have any explanation other than Git bootcamp was initially written > based on my personal setup. > I cloned CPython using SSH, and that's what I wrote in the devguide :) > You can use HTTPS if that works for you. > Perhaps someone else can explain better the difference between cloning via > HTTPS and SSH. Thanks for the clarification - I doubt it matters much whether you use https or git in practice. I've found https better for me because it's more proxy friendly. I don't really know the differences because I've never used git. >> I generally use "Compare and create pull request" >> from my clone's github page, as that seems simpler. > > Note that the link is only visible within 30 minutes (or so) after you > pushed your branch to remote. Ah - I didn't know that, When working on pip, I normally push and create a PR in quick succession. > If you did not create the PR immediately after pushing, the link disappears. > In this case, the instructions in 32.10 will help (maybe?). They will - a lot. Thanks. > Can we assume that people will create their PR immediately? Definitely not, in general. > Maybe an improvement is to mention the "Compare and create pull request", > and to do this immediately after pushing the branch. It might be worth suggesting it as an option, simply so that if a contributor sees the button, they know it's just an alternative approach and it's OK to use. I'll see if I can think of some wording that would help here. > side-topic: Does anyone have some sort of script/git > alias/program/whatchamacallit that will open the PR page once we push to > remote? (similar to what cherry_picker does) That could be a time saver :) I don't - that's the sort of thing I just do manually. (I work on multiple machines, so I'm heavily reliant on minimising the amount of custom scripts and/or setup needed to work on a project. For me, a simple, easily remembered workflow with minimal dependencies on specialised tools works best.) >> 3. The new blurb tool - I presume I'll need to set that up >> somewhere/somehow, and use it to create a news entry. But I can't find >> any docs on it at all :-( > > pip install blurb Doh. I think I recall some discussion about using virtualenvs and maybe that made me think something complex was needed. My mistake. > Some write-up here: > https://devguide.python.org/committing/#what-s-new-and-news-entries Again doh - I don't know how I missed that, thanks. > blurb readme: > https://github.com/python/core-workflow/blob/master/blurb/README.rst Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] New workflow - some questions
On 29 July 2017 at 14:13, Nick Coghlan wrote: > To be honest, the read-only=HTTPS & read/write=SSH split is likely a > Linux+macOS-ism, where we can do "ssh-add" once, and then never have > to worry about explicitly authenticating again until we reboot our > client machine. As Inada-san notes, the password prompt when > accidentally doing a direct push to a HTTPS clone then serves as a > reminder that you probably meant to push to a different remote that's > set up for read/write access over SSH. > > There's no functional difference on the server side though - it's > strictly about how the git client authenticates your identity with the > server. On Windows you can use the git credential manager to store credentials in the OS cert store, and then https is passwordless for push. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Flood of Github review mails?
I've just recently (within the last week I guess) started getting a large number of additional mails from github. For example, I'm getting notifications on https://github.com/python/cpython/pull/3066 which I haven't commented on or been mentioned in, nor am I nosy on the underlying bug. What's changed to cause this to start happening, and how do I make it stop? I've nowhere near enough time to review all the mails I'm now getting, and I'd rather avoid them so I don't miss notifications that I *do* need to see :-( Thanks, Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Flood of Github review mails?
Yeah, looks like that was it. Thanks. Paul On 20 August 2017 at 22:23, Zachary Ware wrote: > Being added to the team caused me to be 'watching' the repo again, even > though I'd previously 'unwatched'. Paul, you may need to unwatch again as > well. > > -- > Zach > (On a phone) > > On Aug 20, 2017 09:28, "Steve Dower" wrote: >> >> We created a Windows team on github and signed it up for notifications of >> changes to PC, PCBuild and the installer folders. If the notifications are >> for files in those folders, that’ll be it. (Though I haven’t noticed any >> similar increase, so it may be something else.) >> >> >> >> Feel free to remove yourself from the team if it looks like that’ll help. >> >> >> >> Top-posted from my Windows phone >> >> >> >> From: Paul Moore >> Sent: Sunday, August 20, 2017 6:08 >> To: python-committers >> Subject: [python-committers] Flood of Github review mails? >> >> >> >> I've just recently (within the last week I guess) started getting a >> >> large number of additional mails from github. For example, I'm getting >> >> notifications on https://github.com/python/cpython/pull/3066 which I >> >> haven't commented on or been mentioned in, nor am I nosy on the >> >> underlying bug. >> >> >> >> What's changed to cause this to start happening, and how do I make it >> >> stop? I've nowhere near enough time to review all the mails I'm now >> >> getting, and I'd rather avoid them so I don't miss notifications that >> >> I *do* need to see :-( >> >> >> >> Thanks, >> >> Paul >> >> ___ >> >> python-committers mailing list >> >> python-committers@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@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] PyCharm open source license
I've been trying out PyCharm recently, and looking through the archives here I see that some time back JetBrains provided us with a free open source license. Is that still running? And if so, how do I go about getting a copy? Thanks, Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] What is a CPython core developer?
On 4 October 2017 at 17:58, Victor Stinner wrote: > 2017-09-22 18:48 GMT+02:00 Antoine Pitrou : >>> * Long term commitement. (...) >> >> Unfortunately we can't evaluate that in advance. Even the person being >> promoted often does not known whether they'll still be there in 5 or 10 >> years. Hopefully that's on their horizon, but many factors can interfere. > > To be clear, I disagree with the "long term commitement", but I tried > to summarize what I heard from other core developers. I think that it > would be wrong to at least not mention it. If most core developers > disagree with this requirement, we should remove it. If there is no > consensus, I prefer to mention it *but* also explains that it's not > strictly a "requirement", but more a "whish". To me, it's about caring about the long-term health of the project, and not just a short-term interest in scratching your personal itch. Sometimes people will only focus on particular areas, and that's fine, but they should be prepared to help out anywhere they can be of use. Equally, people can find that they don't have the time to commit that they used to - again that's OK, but they should care enough to make sure their "area" gets handed over, or is covered by others. Being a core committer is about caring about Python as a whole, and for the long haul. But people give their time and skills where they can, and to the extent that they can. > I will try to clarify expectations in term of time, evenings, weekends > and holidays :-) You don't have to write code at the weekend or while you're on holiday, but you should be thinking about Python ;-) Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Requesting reviews
I'm seeing a lot of review requests from github, asking for reviews from the Windows team. Many of the PRs don't as far as I can see have much Windows-specific about them. It doesn't bother me too much (I just ignore ones I don't have anything to say on) but I thought the idea of having the teams was to ask for specific experts to take a look when needed? As I say, it's not a big deal for me, but I'm curious how others think the review teams should be used. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Requesting reviews
Hmm, as an example, #2858, which seems to be about the AST (which I'm not familiar with). I don't particularly want to single this out as a problem, but it's an example of the sort of request that confuses me - I simply don't know what help I can offer. Maybe there is some suspicion that there might be a Windows element - but without some guidance, I'm not sure where to look. Paul On 6 October 2017 at 16:38, Zachary Ware wrote: > On Fri, Oct 6, 2017 at 7:16 AM, Paul Moore wrote: >> I'm seeing a lot of review requests from github, asking for reviews >> from the Windows team. Many of the PRs don't as far as I can see have >> much Windows-specific about them. It doesn't bother me too much (I >> just ignore ones I don't have anything to say on) but I thought the >> idea of having the teams was to ask for specific experts to take a >> look when needed? >> >> As I say, it's not a big deal for me, but I'm curious how others think >> the review teams should be used. > > Do you have some examples of superfluous requests? I don't think I've > seen any, other than a rash of bad drive-by PRs that merge a > maintenance branch into master, which GitHub should be working on > preventing. See https://github.com/python/core-workflow/issues/168 > for more on that. > > -- > Zach > ___ > python-committers mailing list > python-committers@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Requesting reviews
On 6 October 2017 at 17:09, Mariatta Wijaya wrote: > The windows team is notified because the PR includes changes to PCBuild/* Ah cool. That explains it then - I hadn't spotted that (and didn't think of it). Thanks Mariatta Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Requesting reviews
On 6 October 2017 at 17:58, R. David Murray wrote: > On Fri, 06 Oct 2017 09:09:01 -0700, Mariatta Wijaya > wrote: >> The windows team is notified because the PR includes changes to PCBuild/* > > If you get a review request that says your review was requested "as a > code owner", then it was an auto-request, it wasn't actually requested > by the person named in the message (which I agree is confusing). Ah, right. Yes I had missed that nuance. Thanks, I'm now much clearer on what's going on here. Thanks all for the explanations :-) Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug)
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 ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
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 ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
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. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
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 ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
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 ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
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 ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
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. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email
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 ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Let's give commit privileges to Nathaniel J. Smith
+1 from me also. He's been involved in a lot of distutils-sig stuff as well, and his contributions have always been well thought out and useful. Paul On 24 January 2018 at 23:23, Yury Selivanov wrote: > 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 > mentoring (although I'll be happy to assist Nathaniel in the > beginning). > > Nathaniel has been a prolific PEP author: > > * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521, > PEP 533, PEP 568; > > * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518 > (accepted), PEP 522. > > * Many PEPs mention his name in acknowledgements. > > He also has a few sufficiently complex patches committed, some of > which touch complex areas like ceval loop and signals handling: > > * bpo-32591: Add native coroutine origin tracking > * bpo-30579: Allow TracebackType creation and tb_next mutation from Python > * bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd > * bpo-30039: Don't run signal handlers while resuming a yield from stack > * bpo-30038: fix race condition in signal delivery + wakeup fd > * etc > > He's been very active on python-dev, python-ideas, bugs.python.org and > github. Here's an example where Nathaniel's research helped us to make > a right decision to fix a broken socket object API: > https://bugs.python.org/msg308450. > > He helped me quite a bit with the design of PEP 550 and PEP 567, and > he's doing some interesting work in the async/await area. > > So... let's make it happen? :) > > Yury > ___ > python-committers mailing list > python-committers@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Wanting to merge my first PR under github - a bit of advice
Hi, Cheryl Sabella kindly migrated a patch I'd put on bpo some time ago but forgotten about onto github. The PR (#6158) is ready to go (I think) but this is the first time since the migration to github that I've done a merge, and I'm not quite sure what the workflow is :-( I didn't see much in the devguide (which covers how to write a PR, how to test it etc, but not so much how to merge it, unless I missed something, or it's so simple that the little I did find is all that's needed!) Am I right that all I need to do is hit "Squash and Merge", tidy up the commit message, and that's it for master? This is a doc change which should probably go into 3.7 - so I presume I just add the "Needs backport" label and Miss Islington does the rest? (I assume doc fixes are still OK for 3.7 at this point?) Is there anything else I've missed? (Do I need another approver? I'm assuming not, for a doc fix). Sorry for the dumb questions - if I've missed a glaringly obvious explanation, feel free to let me know. I'm just a little nervous that it's *so* simple I feel I must have missed something! Paul PS Thanks to everyone who has worked on the new github workflow. What I've done so far has been really straightforward, and if I'm right in what I think I need to do above, then you've made the rest of the process beautifully simple, too! ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Wanting to merge my first PR under github - a bit of advice
On 21 March 2018 at 12:42, Nick Coghlan wrote: > On 21 March 2018 at 06:58, Paul Moore wrote: >> >> Hi, >> Cheryl Sabella kindly migrated a patch I'd put on bpo some time ago >> but forgotten about onto github. The PR (#6158) is ready to go (I >> think) but this is the first time since the migration to github that >> I've done a merge, and I'm not quite sure what the workflow is :-( I >> didn't see much in the devguide (which covers how to write a PR, how >> to test it etc, but not so much how to merge it, unless I missed >> something, or it's so simple that the little I did find is all that's >> needed!) > > > You didn't miss it - https://devguide.python.org/committing/ is still pretty > much written for the old approach of merging on the command line. > > So a devguide issue would definltely be appropriate, and if you're so > inclined, even a PR with the docs that you wish had existing when you looked > for them :) I'll certainly try to find some time to put something together. For now, I've raised https://github.com/python/devguide/issues/347 to track it. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Wanting to merge my first PR under github - a bit of advice
On 21 March 2018 at 14:02, Mariatta Wijaya wrote: > Some steps were written here: > https://devguide.python.org/gitbootcamp/#accepting-and-merging-a-pull-request > > And the section right after explains the backport. Thanks Mariatta - that's exactly what I was looking for. > I guess it needs reorganizing. It's depressing how often the problem is not about providing the information, but about helping people find it. I was *almost* there - I remember skimming the pages about git, but as I know git itself, I was assuming it was about git for people who didn't know it, rather than "how the CPython workflow uses git" and missed that bit. I'll see if I can think of a way of making it a bit more obvious. > Top posted from my phone while literally on a beach. I'm jealous :-) Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?
On 2 May 2018 at 10:49, Victor Stinner wrote: > 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: Do we really need this spilling over into yet another mailing list? Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?
FWIW, -1 from me. At least with the PEP as it stands. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposing Mark Shannon to be a core developer
+1 from me :-) On 14 May 2018 at 21:41, Larry Hastings wrote: > > > 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 to the > "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no. At the time he said he didn't like our > antiquated workflow. Now that we've switched to the git-based core dev > workflow, this objection is gone, and he's now interested in accepting the > commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be surprised > at the current state of affairs. I'm expecting a load of "you mean Mark > *isn't* a core developer yet?" replies. > > > Submitted for your consideration, > > > /arry > > ___ > python-committers mailing list > python-committers@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] A different way to focus discussions
On 18 May 2018 at 23:25, Guido van Rossum wrote:
> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)
It's not scalable, certainly. But it's still (IMO) fine for all but
the larger PEPs - the trick is spotting which PEPs are "too big" :-)
I'm not sure that the issue with python-ideas is that bad. That list
is *designed* for incomplete and unformed proposals, and so long
threads are common (and accepted) on there. People on python-ideas are
used to skimming or ignoring/blocking threads they aren't interested
in. So by the time things are ready to go to python-dev (or wherever)
there's a good sense of whether the PEP is likely to be controversial.
I'd suggest that this is the point when the decision to go to
python-dev or github could be made.
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.
>
> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.
>
> PEP authors may also choose to use a different repo hosting site, e.g.
> Bitbucket or GitLab. We can provide a script that allows checking the
> formatting of the PEP easily (basically pep2html.py from the peps repo).
I would prefer that PEP repos remain on github, and that once the PEP
is finalised (accepted, rejected, whatever) moved under the CPython
organisation (the whole repo, issue tracker, history, everything) so
that the history of discussion isn't lost. Current PEP discussions are
retained on the list archives, and I think the discussion history is
valuable (even if a lot of it ends up being noise at the moment). I'd
rather not have to maintain extra accounts for bitbucket or gitlab,
and learn how notifications and tracking work on those platforms. A
common interface is important. Adding barriers to contribution does
filter out casual commenters, but I'm sure we don't want to be seen to
be deliberately making it *hard* for outsiders to get involved.
> Using a separate repo per PEP has the advantage that people interested in a
> topic can subscribe to all traffic in that repo -- if we were to use the
> tracker of the peps repo you would have to subscribe to all peps traffic.
>
> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
(Later)
> I want to completely avoid discussion on python-dev. This probably means we
> should never post the full text of the PEP there. (We may have to amend PEP 1
> to support this.)
Avoiding *discussion* is probably OK. But regular summaries of
progress would, I think, be critical. Otherwise python-dev is
essentially cut out of the loop, and this becomes more of a change in
governance, as Antoine mentioned.
I'm not quite sure what your intention was, but I'd like to see a
series of announcements on python-dev for a PEP which is being
discussed offline:
1. An initial announcement of the creation of the PEP repo, giving a
summary of the PEP (the abstract from the proposal), and a pointer to
where interested parties should go to participate in discussions.
2. Progress announcements, maybe once a month, repeating the summary
and adding a "what has changed" summary.
3. Preliminary announcement of the decision on the PEP (a "release
candidate" if you like) stating that the decision has been made, what
that decision is, and that it will be officially announced in (say) a
week.
4. Final announcement, giving the summary, the decision, and pointers
to the final PEP text and the discussion (now hosted permanently under
the cpython org on github).
The point of the "release candidate" stage is the same as the RC for a
release - last chance to raise showstopper problems, plus announcing
the start of the "release" work (moving the repo, specifically).
I'm not that wedded to the RC announcement, but it will avoid the
final decision coming as a complete surprise to python-dev. As a data
point, I currently have no idea whether the discussions on the binding
expression PEP are still just rumbling on, or whether a decision is
imminent. Of course, if the progress announcements are sufficiently
good, the RC may not be necessary (it would effectively just be the
last in a series of summaries).
Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Changing commiter status
On 18 June 2018 at 20:41, M.-A. Lemburg wrote: > On 18.06.2018 21:07, Guido van Rossum wrote: >> Hm, unless I misunderstood, MAL's >> >>> Being a core developer of Python is a status >> >> suggests that core devs might want to keep this status since it confers >> "status" on their person (it looks good on a resume for sure). And I >> wouldn't want to make it any harder for a 3rd party to verify someone's >> claim to this status in their resume. >> >> Marc-Andre, is that what you meant? > > I guess I wasn't clear, sorry. > > Perhaps the better term is "title" rather than "status". My > understanding is that you become core developer and essentially > keep this title forever. > > Whether you actually have your keys in the repo to push a PR > or not is a different story and not really related to the "title" > you earned. > > Listing the core developers somewhere on an official page > would help with the verification you are referring to. At > the moment, we don't seem to have this. It does make a difference > on CVs and it's one of the few things we can give back to people > when contributing code and time to Python. Just to add my thoughts here. I agree that "being a Python core developer" is something people can be proud of (I know I am!), as well as being good to put on a CV. It would be a shame to devalue that pride by saying in effect that you're no longer a "real" core developer if you don't keep contributing. So I'd very much like to distinguish the idea of "being a core developer" from the administrative management of commit privileges. The respect and gratitude of our peers is one of the few things it's possible to get as a reward for open source contributions - let's be generous with that (and with openly acknowledging it). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
On 12 July 2018 at 15:57, Guido van Rossum wrote: > But I'm basically giving myself a permanent vacation from being BDFL, and you > all will be on your own. I just want to echo everyone else's sentiments and say thank you for all the work you've done, and for the example you've set to all of us. Like many others here, my life would have been quite different without Python. Even though I've never met you in person, you've been a huge influence for me. Best wishes for the future. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] PEP stewardship delegation: the minimal change approach
On 14 July 2018 at 08:05, Nick Coghlan wrote: > So stealing Brett's excellent suggestion of "Design Steward" as a > BDFL-independent term for the current BDFL-Delegate role, a potential > PEP 1 amendment for the appointment process would be: I've only got one peripheral point to make here, but can we keep the term "BDFL" and its derived terms? Even if we no longer have a BDFL (although the "FL" means that Guido is still our BDFL, even if he has stood down from the actual day to day responsibilities), Carol made the important point that Python is about community as much as it is about a programming language, and that community is built around the BDFL. I think it's important for the community that we continue to acknowledge the place of the BDFL in that role, even if it's now a notional position. As a British person, I suppose I think in terms of the royal family. No actual function in terms of government, but important in what many people (both within and outside Britain) consider being "British" to mean (apologies to any republicans out there). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] An alternative governance model
I also agree 100% with Barry's proposal. I think he's absolutely right that one of the important features of Python (both the language and the community) is the single focus and vision of the BDFL, and reading Barry's mail crystallised for me the unease I felt about the proposals around a Council, which is precisely that they wouldn't provide that unified vision. Having a council acting as support for the NBDFL gives the best of both worlds. Strong +1 all round. I too would love to hear Brett's thoughts, but he definitely has my support if he feels able to take on the role. Paul On 18 July 2018 at 04:20, Carol Willing wrote: > I wholeheartedly agree with Barry's suggestion. > > It offers a single person who can communicate the design vision. While the > support of a council will help spread out the work and provides a great way > to grow future leaders and a smooth transition if for any reason (family, > work, health, etc.) the new BDFL has to take a break. > > On Tue, Jul 17, 2018, 7:38 PM Ned Deily wrote: >> >> On Jul 17, 2018, at 22:15, Eric V. Smith wrote: >> > On 7/17/2018 10:02 PM, Barry Warsaw wrote: >> >> I’d like to propose an alternative model, and with it a succession >> >> plan, that IMHO hasn’t gotten enough discussion. It’s fairly radical in >> >> that it proposes to not actually change that much! >> >> TL;DR: I propose keeping a singular BDFL and adding a Council of >> >> Advisors that helps the BDFL in various capacities, with additional >> >> responsibilities. I also have someone specific in mind for the NBDFL, but >> >> you’ll have to read on for the big reveal. >> > I've come to this same conclusion. I think Brett would be a good choice, >> > and I'd support him, but I think the more important part is that it be a >> > single person. >> >> +100. I think Python owes much of its success to both Guido's ongoing >> vision *and* his clear role as leader. Up to now, we have not had much >> experience governing by committee or council and I think it may be a mistake >> to try to implement that now (although we *do* have some successful >> experience with informal council of advisors models, for instance, in the >> release management area). While it wouldn't necessarily be a good choice >> for many (most?) open-source projects, I think the NBDFL-plus-advisors model >> would work well in the relatively congenial and respectful environment of >> the current Python committers community. That's not to say that we won't >> collectively decide down the road that we want to try something different >> but trying to keep this really important transition (i.e. from Guido) as >> simple as possible initially would be a really smart thing to do. >> >> > And I think the succession plan is important, too. I think Łukasz was >> > alluding to this earlier (or maybe I'm projecting): who's to say that the >> > next BDFL is legitimate? If we put together a plan, and Guido blesses it, >> > that makes the plan legitimate, and then the plan gets executed and makes >> > NBDFL legitimate. >> >> That, too. >> >> -- >> Ned Deily >> n...@python.org -- [] >> >> ___ >> python-committers mailing list >> python-committers@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@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions
On 19 July 2018 at 08:33, Antoine Pitrou wrote: > > Le 19/07/2018 à 04:36, Nathaniel Smith a écrit : >> [tl;dr: We need some ground rules, because uncertainty makes it hard >> to think straight. But if we get sucked into a complicated meta-debate >> about the ground rules then that defeats the purpose. My proposal for >> a Minimum Viable Ground Rule: let's all agree not to finalize any >> governance decisions before October 1.] > > +1 from me. Thank you. +1 from me too. You make very good points (particularly regarding the "fear of something happening while I'm not watching" factor). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions
On 19 July 2018 at 20:44, Brett Cannon wrote: > But the amount of discussion can be unbounded (considering people write PhD > theses on governance models and voting systems we could talk about this > stuff forever ;), so putting a schedule in place to help focus the > discussions can be beneficial. > > I'm +1 on Mariatta's schedule. That gives people more than 2 months to come > up with governance proposals and all of us to settle on how we will vote. > And if we say the month of November will be when voting is open then that > would give people more then 3 months notice of when the first vote will > occur. As long as we understand that the deadline is intended to help focus discussion, and not to pressure a premature or rushed decision, I think Maraiatta's schedule is fine. If, coming up to that date, people feel the need for more discussion/review, it should be easy to extend the timescale. I'd like to think no-one is going to demand an extension simply to delay the process, and conversely I assume that if someone *does* ask for an extension, that request would be treated with respect and consideration. So while I think a concrete timescale will help focus the discussion, I don't think it should be viewed as set in stone (otherwise we'll just have yet another debate on what precise dates we should choose!) Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] And Now for Something Completely Different
On 20 July 2018 at 12:57, Victor Stinner wrote: > Hum. Let me try to explain my point differently. Currently, some > people don't read PEPs just because at the end, only the single BDFL > vote counts. What's the point of spending hours (if not days) on > reading a long PEP and the long discussion on mailing lists, if your > count doesn't count? My suspicion is that *most* people who don't read PEPs don't do so because they don't have the time, not because they don't believe that their opinion will matter. In actual fact, the evidence from many threads is that people are more than happy to express their opinion even though they haven't read the PEP. So I doubt that giving people more power to affect the result will make little practical difference. > Now imagine that all votes count. I expect that > people will spend more time on reading carefully each PEP and follow > more closely discussions since they will be de facto more involved in > the decision process. In contrast, I would imagine that people would continue to discuss PEPs in exactly the same way that they currently do, so the result would be that the votes are based more on partially-informed opinion and "gut feeling". Certainly some people will work harder to provide an informed vote, but I doubt that will be true in the majority of cases. Worst case, people will feel a responsibility to vote, but won't have any more time than they do right now so they'll vote with limited information simply because "it's expected of them" to vote. I suspect that the reality will be somewhere between these two extremes. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, 2 Aug 2018 at 01:58, Yury Selivanov wrote: > > On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya > wrote: > [..] > > Please don't misunderstand my wanting to set up a deadlines and process as > > wanting to rush things. > > Absolutely, I understand, I didn't want to imply that "[name] is > rushing the process". Sorry if I sounded this way. I do have an > impression, though, that a large population of core devs is OK with > deadlines and the other sizable population doesn't understand why we > need a strict schedule right now. I think this is an important point. I'm also -1 on a strict timetable here - I agree with the points Marc-Andre and Nathaniel made, and I don't want to see us rushing into a decision. It actually strikes me that the disparity here (with some people wanting to keep the process moving and get something sorted so we can get back to normal, and others wanting to let things take their time and not force a decision simply because "we need to decide") is an excellent test case for how we make decisions in the future. If we can't reach a mutually satisfactory agreement on how to move forward on this, I don't have high hopes for the possibility of our choice of governance model being acceptable to everyone. > > I'm open to extend the dates, and even wait another year if we need to. > > Or do folks want to come up with a completely different process than what > > I've proposed? > > > > In the end, I just want to know whether we will come to decision before > > 2019, 2020, 2021, 2022, .. ? At the moment, I'm not even sure I want to know that much. For now, what I want to know is how things are going to feel now that we don't have Guido acting as BDFL. That's going to take time to assess, but until we have done that, I don't see how we (as a community) can have any sort of good idea about what sort of governance works for us. What I'd like to understand from the people advocating a fixed timetable and agreed dates, is what *actual* problem does fixing dates solve? Are bpo discussions being held up for lack of a BDFL? Are people not committing changes? Certainly we're not accepting PEPs at the moment, but it's not like PEPs work on a rapid timescale anyway - and if the problem is that without a BDFL, the discussions feel directionless, then that's a *specific* problem we can solve without needing to agree a governance model (it's the "guiding discussions" aspect of Guido's role, as opposed to the "BDFL" part). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, 2 Aug 2018 at 08:50, Steven D'Aprano wrote: > Indeed. A hard deadline concentrates the mind. It doesn't need to be > tomorrow, I think your choosen dates are a great balance, neither too > quick nor too drawn out. But it also encourages people (particularly people with limited free time) to rush decisions, and focus on "getting something done in time", rather than "doing the right thing". Balancing those two pressures is not easy, and the balance point varies significantly between individuals. > If Python is still rudderless by Christmas, I think we have failed. Do you really consider Python "rudderless" at the moment? I only really see two threads (excluding this one ;-)) that could give that impression - "None-aware operators", where the discussion was deliberately re-opened when Guido stepped down, to have a debate in the absence of a BDFL (a decision which I personally feel was ill-advised, but which IMO excludes it from any consideration in this context) and the discussion on optimising PyCFunction (which is highly technical, and has 2 specialists disagreeing - that's pretty much guaranteed to drag on for a while). Most things are carrying on as usual (with a certain level of people wondering what will happen, but not in a way that's blocking activity). I honestly think that describing the current situation as "rudderless" and a "failure" if it carries on, is a pretty big exaggeration. Maybe at worst, Python 3.8 will be relatively light on new features, but that's not necessarily a bad thing (and yes, I understand that's a decision by inaction. but personally I'm OK with it). Not so much a moratorium, as "taking a breath". Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel
On Fri, 14 Sep 2018 at 20:29, Raymond Hettinger wrote: > > At the developer sprints this week, we collectively decided to grant core > committer status to Emily and Lisa. > > Please join me in welcoming them to the team. Congratulations and welcome, Emily and Lisa! Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)
On Thu, 20 Sep 2018 at 21:37, Antoine Pitrou wrote: > > > Apparently it's this one: > https://mail.python.org/pipermail/python-ideas/2018-September/053482.html > > By the way, regardless of this single case, I would like people to think > of the broader issue we're having. It's more than a single contentious > decision. Before I say anything else, I want to point out that (a) I'm not objecting to the ban, or the process that took place to impose it, and (b) I'm extremely appreciative of the work our moderators put into trying to police things in an increasingly difficult environment. So please take anything I say in that context - as perspective from someone who is concerned about the direction that certain of our groups are taking, but understands that it's not an easy problem to solve. But in the interest of looking at the broader issue (which I agree with Antoine is something we should be concerned about)... I understand that the taboo in question is a strong one in American culture, and as such violating that is inconsiderate and insensitive. Doing so deliberately is both unacceptable, and a cheap form of debate (if giving offense is the only way you have to make your point, maybe your point's not good enough?) But it is still very much one culture's position, and American sensibilities often seem to be very clear and present in a lot of the debates we see that "get out of hand" in one way or another. I'm British (and my age may also be relevant - I grew up in the 1960s and 70s), and from my perspective, it feels like a lot of people are over-sensitive, and very quick to perceive offense - to the extent that entirely natural (to many British people) and accepted tones, like sarcasm and irony, are almost impossible to express without having to completely obscure meaning by adding clarifications and explanations. I'll also comment on the point made here, can anyone point to a non-American taboo that has been violated and hasn't been dealt with the same way? Not really, but in my case that's because I don't think the British *have* strong taboos like that (and Antoine indicates that the same is true of the French). The only thing I can think of is religious taboos, such as Muslim concerns about taking the name of the Prophet in vain, but I don't think I've ever seen that sort of violation (and I would expect that to be dealt with just as swiftly). Personally, as a Catholic, arguing religious taboos on a list about a language based on Monty Python feels ironic anyway - but for the record, please don't ban references to the Spanish Inquisition or the Holy Grail on my account :-) Openness needs to be a two way street, in my view. Certainly people from cultures that have a more "robust" (shall we say) natural form of expression need to be aware that other cultures and people may not be able to deal with that - but conversely, people from cultures with a strong sense of certain words and expressions being unacceptable need to be open to the fact that others don't have that sense, and expect thicker skins in debate. That's not how I see the Python community going at the moment - rather we're moving towards a "lowest common denominator" approach, where *everyone* needs to skirt around all possible forms of offense, and the person claiming to be offended is in effect always in the right. That, to me, is taking the easy option, and I think that the Python community should aspire to do something better than that, even if it's hard. The internet in general is a hugely beneficial technology, allowing us to interact with people in radically different cultures and situations than we were ever able to in the past. That's a massive step forward for humanity as a whole in understanding each other - and we shouldn't undermine it by putting up barriers to communication in the form of preventing people from making (and learning from) dumb social mistakes. As things stand, everyone is living in fear of giving offense. As an example, some time ago, I was participating in a discussion where some participant made a comment that I thought was a bit out of line with the list's policy,. It didn't bother me, personally, at all (as I say, I'm British :-)) but rather than let it lie, I felt that I should mention this, rather than leave it to someone else. However, what ended up happening was that I got a lot of criticism for "taking offense unnecessarily". (I don't have a link, and I don't want to provide one - it's an example, not something I feel the need to analyze further). So rather than *helping*, I ended up being the bad guy simply from trying to channel other people's views and getting it wrong. And I ended up with a strong sense that everyone viewed me as the sort of over-sensitive complainer that I try very, very hard not to be. When I write mails for the lists, it's an exhausting process. The technical content is easy, but policing my own tone against an increasingly complex and restrictive set of standards that I
Re: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)
On Fri, 21 Sep 2018 at 12:38, Carol Willing wrote: > Much of the discussion here has focused on the use of a few words. > > IMHO, discussing violence, assault, and implying that its okay to accept and > trivialize this violence do not belong in posts about the Python language. > > From the original post: > > Being triggered by a word this simple is not exactly a > sign of mental stability. I know a girl who's been raped more than she can > count - but the word doesn't trigger her like this(only makes her want to > beat up rapists). If people can do that, then surely a playground insult > wont reduce you to tears, right ? I agree - *but* there's a whole lot more I wish I could say, about context, and looking at how the conversation reached that point. But I won't, because frankly I'm scared to do so. I don't trust myself to explain my feelings without doing so in a way that people find offensive, and suffering a backlash that I didn't intend to trigger, and which won't help the discussion. I'm not sure that "I'm too scared to participate in this discussion" is where we want to be, though... Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)
On Fri, 21 Sep 2018 at 13:26, Carol Willing wrote: > Context is important. I wonder though if the author's intent was constructive > comment... I'm sure it wasn't. But in context, it was a statement made in a thread that had long previously become nothing more than non-constructive invective. Calling one person out (even though his comments were significantly more extreme than others') strikes me as looking for a culprit, rather than addressing the situation. It's not likely to be a practical option on a mailing list, but in primary school (which the whole conversation felt like) a likely response would have been to put *everyone* involved in a time-out for a period of cooling off, to think about how their behaviour was unacceptable. Think for example of a group of kids taunting each other until one of them snaps and hits someone. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)
On Fri, 21 Sep 2018 at 13:30, Donald Stufft wrote:
> So part of being and open and welcoming community, is knowing and
> understanding that words, images, etc like that can make people feel like
> we’re either a group that will directly engage in those attacks that have
> been associated with them in the past, or at least won’t come to their aid if
> someone does initiate those kinds of attack.
I'm going to take this one comment and respond to it out of context.
But generally, I agree with everything you said.
My biggest concern is that we're starting to build a community where
people feel exposed to attack for "CoC violation" accusations over
simple misunderstandings, or careless wordings. Or, for that matter,
using terminology that they weren't aware was unacceptable. Not "being
called out (by the offended party), apologising and moving on", but
going straight to policy complaints by people (maybe even people not
directly upset) assuming offense could be claimed. That's clearly
nothing like the sort of problems people with real reason for
sensitivity have to live under, but nevertheless it's not a
comfortable place for people to learn how to interact.
Balance, forgiveness, and a mature level of empathy are what's
*really* needed ("among the things that are needed...":-)). Not
policies. Policies should be weapons of last resort.
Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Council / board (Was: 1 week to Oct 1)
On Tue, 25 Sep 2018 at 15:28, Mariatta Wijaya wrote: > > My proposal is taking into consideration The PSF's mission and diversity > statement. I will not remove the diversity clause from PEP 8011. > > To save us all trouble of discussing this particular issue, for those of you > who disagree completely, and have other ideas about how you'd like Python to > be governed and who should be in it, you can do one or more of the following: > > - not vote on my PEP > - vote on the other PEPs > - write their own PEP Or presumably - discuss the concerns during the debate phase of the process ? At the moment the discussion seems to be about a possible misinterpretation of a possible misquote of something the PEP might end up saying. It seems like it's probably worth waiting until the facts are clear before saying anything more. But once there's an actual PEP (not a placeholder) in place, I assume that discussions about the content *will* be acceptable (as long as they are reasonable and respectful, obviously). I don't recall the expected details of the actual process (if they've been published yet) but I don't expect them to be simply "here's the PEPs, let's vote!". Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Python 4.0 or Python 3.10?
On Tue, 25 Sep 2018 at 20:32, Antoine Pitrou wrote: > > > Le 25/09/2018 à 21:30, Yury Selivanov a écrit : > > What's the current plan for what version of Python we release after 3.9? > > > > The reason I'm asking this is because I frequently need to refer to > > *that version* of Python in the documentation, especially when I'm > > deprecating APIs or behavior. Right now I'm saying "Python 4.0" > > implying that 4.0 will be released right after 3.9. > > > > I've heard multiple opinions on this subject. One of them is that we > > should release 4.0 when we have a major new change, like removal of > > the GIL or introduction of a JIT compiler. On the other hand, we have > > no estimate when we have such a change. We also don't want Python 4.0 > > to be backwards incompatible with Python 3.0 (at least not at the > > scale of 2 vs 3). So to me, it seems logical that we simply release > > Python 4.0 after Python 3.9. After all, after 3.9 Python will be > > drastically different from 3.0 and from 2.7. It sounds better. :) > > Many people have bad memories of the Py2->3 transition, so I think we > should avoid triggering their sensitivities by announcing a Py4 if > there's nothing, in terms of changes, to justify the jump. > > So my preference would be on 3.10. I agree. 3.10 seems like the best choice. Even though we don't expect 4.0 to be a major breaking change like 3.0, people do assume something like semantic versioning, and therefore expect 3.9 -> 4.0 to be a "bigger" change than 3.9 -> 3.10. One thing that *will* need work is places that assume single-digit version components (for example the wheel spec uses pyXY to mark compatibility with Python X.Y - that will need tweaking to allow for 3.10). IMO, we should make it clear sooner rather than later that version numbering will be going 3.8, 3.9, 3.10, 3.11, ... to give people a chance to prepare. Otherwise we might inadvertently have another major compatibility issue right after 3.9 :-( The uncertainty simply lets people assume whatever's least disruptive for them, and not be ready. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Python 4.0 or Python 3.10?
On Wed, 26 Sep 2018 at 18:15, Yury Selivanov wrote: > > On Wed, Sep 26, 2018 at 12:28 PM Brett Cannon wrote: > [..] > >> What is the status of Brett's UNIX Python launcher "py" by the way? > > > > > > You can see the current TODO list at > > https://crates.io/crates/python-launcher . Basically I need to implement > > "--help" and "--list" to fill in the last two low-hanging fruit features, > > but at long as you don't need to customize the search mechanism then it's > > already working. And BTW it's already compatible with either 3.10 or 4.0. :) > > Looks like it's possible to either request a specific version (e.g. > 3.6), or a major version (e.g. any Python 3). Is it possible to > request "3.6 or greater (be it Python 3.10 or Python 4.0+)"? That's not possible for the Windows launcher. As the idea is to have a uniform interface for the Windows and Unix launchers, I'd assume that this would need to be a feature request for both the Windows and Unix launchers. (It's a reasonable-seeming idea, but I don't know how useful it would be in practice - can you give some examples of use cases?) Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, 29 Sep 2018 at 09:23, Łukasz Langa wrote: > > > > On Sep 29, 2018, at 08:50, M.-A. Lemburg wrote: > > > > I hope it does, since otherwise python-committers is not only moving > > to discourse, but also losing its functionality as forum for > > core developers. We'd just have another python-dev or python-ideas > > forum. > > I assume it's the faulty mailing list medium that made you miss my response > to Barry where I say that this is indeed supported ;-) > > See, Discourse would already save you a paragraph of worry. Why don't you try > it out for a while and see how it feels? I understand the power of habit but > I promise you that there's plenty of things that make the adjustment > worthwhile. I mentioned something similar on Discourse, but I'm going to add a comment here. This sort of dismissal of the validity of other people's long-established workflows is not very helpful. I use email, It's not because I've no idea how to use web forums, nor is it because I'm an old fuddy-duddy. It suits my workflow. I use a *lot* of web forums, as well as tools like Stack Overflow, reddit, Discord, etc. They simply do not always suit my requirements as well as email. Some examples: 1. Pull technology rather than push. The fact that email is *delivered* to me is a critical benefit for certain types of interaction, and one that's far too easily dismissed by people who promote pull solutions. It's baffling to me that such a fundamental difference is routinely treated as "minor". 2. Email-forum interfaces are in my experience uniformly suboptimal. I'm OK with the idea that I need to compromise and not expect people who prefer a forum to do all the work, but nevertheless, seeing the typical email response appear in a forum (with quoted text, signatures, etc) is very disruptive to conversation flow. 3. Maintaining accounts for various bits of forum software is a pain when you use as many devices as I do. 4. Browser tabs. Some of my devices are close to unusable *already* because of the RAM usage of my browser with multiple tabs open. Is someone going to suggest that there's a minimum hardware requirement to participate? Can we please consider that people have a lot of investment in email, and being willing to try a new approach is a big commitment. Responding to valid concerns with "just try it, you'll like it" is pretty non-constructive. Paul PS I *am* trying Discourse out. I'm somewhat interested in a "better than email" solution. So this is emphatically *not* a "do things my way or I won't play" posting. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, 29 Sep 2018 at 09:57, Nick Coghlan wrote: > > On Sat., 29 Sep. 2018, 11:19 am Barry Warsaw, wrote: >> >> On Sep 28, 2018, at 17:45, Łukasz Langa wrote: >> >> > Do you use NNTP? Like with IRC, you won't find the next generation of core >> > developers on it. And no, there is no support for it in Discourse. >> > >> > We could probably figure something out with Gmane if there's interest. >> >> Yes, I use NNTP to read many of the Python mailing lists. Gmane, even in >> its current state, is fantastic. >> >> I’m all for supporting the next generation of developers, but not >> necessarily at the expense of *decades* of established workflow for current >> developers. Moving to Discourse breaks this and proliferates browser tab >> syndrome. It’s an experiment worth conducting, but I do think it’s a bit >> cavalier to shut down python-committers without further discussion. > > > Especially on the eve of critical governance discussions that will heavily > impact the future of python-dev. > > This is exactly the kind of arbitrary decision making by an insufficiently > representative group that led to us banning making any binding decisions at > language summits: their in-person nature means that they're inherently > exclusive environments that lead to requirements being overlooked and > decisions being made without involving most of the people affected. Strong +1. We've yet to see most of the governance PEPs, and now it's looking like the people involved in debating them will be hampered by struggling with a new communication medium as well? And the new medium was announced as a completely out of the blue surprise to most of us? Suggestion: We mandate that all discussion on governance must remain on the mailing list, and discussion on Discourse will be banned. That way, no-one who is in the process of switching and doesn't yet feel comfortable with the new medium will feel disenfranchised. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, 29 Sep 2018 at 10:24, Nathaniel Smith wrote: > > On Sat, Sep 29, 2018 at 1:51 AM, Serhiy Storchaka wrote: > > 29.09.18 03:45, Łukasz Langa пише: > >>> > >>> On 28 Sep 2018, at 23:04, Serhiy Storchaka wrote: > >> > >> Do you use NNTP? Like with IRC, you won't find the next generation of core > >> developers on it. And no, there is no support for it in Discourse. > > > > > > Yes, I do. I read all Python-related mailing list via the Gmane gate. It is > > convenient in case of large discussions, when I can read selected branches > > and ignore others. The great advantage of NNTP is that it provides access to > > past discussions. I can read Python-Dev discussions back from 1999. > > The reason the general public has settled on web forums rather than > mailing lists is basically that web forums give you many of the > advantages of NNTP -- including first-class access to archives, > replying to threads that predate your arrival, muting topics, the > ability to skim the topic list before downloading everything, etc. -- > without the need to install specialized software. Of course it's not > going to be the same as your favorite NNTP client that you've spent a > decade tweaking, but it might be worth giving it a try? I don't use NNTP, but this is simply wrong. Forums miss one of the most significant advantages of NNTP - namely, the choice of client enabled by having a standardised protocol. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, 29 Sep 2018 at 11:04, Nathaniel Smith wrote: > > On Sat, Sep 29, 2018 at 1:53 AM, Nick Coghlan wrote: > > This is exactly the kind of arbitrary decision making by an insufficiently > > representative group that led to us banning making any binding decisions at > > language summits: their in-person nature means that they're inherently > > exclusive environments that lead to requirements being overlooked and > > decisions being made without involving most of the people affected. > > Did you see Brett's email here, especially the last few paragraphs? > > https://mail.python.org/pipermail/python-committers/2018-September/006100.html > > I don't know how the Discourse experiment will turn out, and I know it > won't make everyone happy, but I hope it works. Because we *know* that > what we're doing now is making people miserable and driving them away. > The push to try Discourse may or may not be misguided, but it's not > coming out of a few people having a whim over lunch together. Who's "we"? I thought I was part of "we" when it came to the Python core dev team... > P.S.: I found that link using my usual method for finding mailing list > archive links, which is: first I did a search in my local MUA, found > the email I wanted, noted the date, then manually went to the mailing > list archives and clicked through the messages around that date until > I found it. This *sucks*. But at least it was *possible*. Personally I do a Google search rather than using my MUA, but the point is that while it's clumsy, it's known technology. I don't even know how I'd find a link to an old message in Discourse, but I assume it's not searchable via Google? Sure, I can learn. But how about a member of the general public (after all, python-committers is supposed to be restricted for posting, but publicly visible)? On Sat, 29 Sep 2018 at 10:40, Łukasz Langa wrote: > > Hold on. Out of the 30-something committers active in the past two releases, > 20-something were at the sprint. (I can pull more detailed stats but I'm on > the phone now.) Setting up Discourse with the intent of replacing the mailing > lists met no opposition at the sprint. By all counts, the group was > sufficiently representative and involved most of the people affected. Hold on in return. Are committers *not* active in the past two releases not considered? Your figures seem biased. (Was I part of that 30? I committed some changes in the last 2 releases. Barely anything, and I do *not* consider myself very active in terms of code changes, but how many tiers are we working with here? People who were at the sprints, people "active in the past 2 releases", "the rest"? I don't want to seem to accuse people of agendas - everyone's acting in the best interests of the community - but it does feel like the community is fragmenting at the moment :-( Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, 29 Sep 2018 at 11:29, Donald Stufft wrote: > Discourse is perfectly searchable using Google in exactly the same way as > Mailman archives. Cool. > It also has built in search. Somewhat less relevant - I assumed that but "most people" won't use that, they'll use Google. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, 29 Sep 2018 at 11:44, Łukasz Langa wrote: > > > On Sep 29, 2018, at 11:24, Paul Moore wrote: > > Are committers *not* active in the past two > releases not considered? Your figures seem biased. (Was I part of that > 30? I committed some changes in the last 2 releases. Barely anything, > and I do *not* consider myself very active in terms of code changes, > but how many tiers are we working with here? People who were at the > sprints, people "active in the past 2 releases", "the rest"? > > > There is discussion *just* about this here: > https://discuss.python.org/t/which-list-of-core-developers-is-authoritative/55 Isn't that just a restart of the conversation that happened on this list not too long ago (prompted by a question from MAL, IIRC) but missing the context of that previous question, and with less participants (so far)? Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] python-committers is dead, long live discuss.python.org
On Sat, 29 Sep 2018 at 12:06, Łukasz Langa wrote: > > > On Sep 29, 2018, at 12:02, Paul Moore wrote: > > > > Isn't that just a restart of the conversation that happened on this > > list not too long ago (prompted by a question from MAL, IIRC) but > > missing the context of that previous question, and with less > > participants (so far)? > > Did you read it? I address this in the original post. I even link to the > committers discussion. > > The context is not missed but different. I thought I did, but I've reached a point where I'm struggling to follow the various threads and posts. At the moment, I've burned out on trying to cope with both email (for all my non python-committers emails) and Discourse, so I'm struggling to follow discussions. I'll probably stop following python-contributors for the rest of the day, and hope I can catch up on what I missed tomorrow. I consider that a negative indication of the usability of Discourse for me, but I'm willing to mark it down as "early days" for now. Apologies for misreading the mail in that thread. For the record, and adding it here because I'm done with Discourse for the day, I consider myself a core Python developer, and I am proud to do so - I enjoy being able to say that. I'm *not* particularly active in terms of commits - there are a number of reasons for that (other commitments, struggling to keep up with the details of the CPython workflow, ...) but it's a reality. However, I *do* contribute a lot to discussions, as I always have, and I feel a great responsibility to do that "as a core developer" and always try to ensure that my posts in that context are for the benefit of the language. I would fight to retain my right to call myself a "core Python developer", with the same implications as anyone else (I do *not* want to call myself "Emeritus" or "Inactive" or any of the other terms previously mentioned for "not contributing much these days"). I would feel very disappointed and rejected if it became the case because I didn't commit actual code, and I don't attend conferences/sprints, that my views were ignored or under-represented. I'm concerned already that it's becoming harder and harder to be heard in the core dev community. I'd really like it if experiments like Discord made it *easier* for people to be heard and represented - but I fear that they won't, and the voices of people with real life commitments that make working with forum software harder will be lost (and not having a good way for people to communicate "I can't effectively communicate via this new mechanism" is a particularly pernicious way of losing people's input). I'll catch up with discussions again in a day or two. For now, I need to go and read my emails :-) (Yeah, that's a joke - I really need to go and hang out with my family). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Sat, 3 Nov 2018 at 02:37, Victor Stinner wrote: > > According to the PEP 8001: "The vote will happen in a 2-week-long > window from November 16 2018 to November 30 (Anywhere-on-Earth)." It's > now in less than two weeks. > > I see that the PEP 8001 is still being updated (voting method). Should > we still expect new changes before the vote starts? Can we set a > deadline, like November 15 (Anywhere-on-Earth)? > > Nathaniel Smith and Donald Stuff have a draft PEP 8016 which is still > at the "ideas" stage: > https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/28 > > What is the deadline to submit new governance PEP and to update > governance PEPs? November 15 (Anywhere-on-Earth)? Following on from this, where and when is the discussion on PEPs happening? I guess maybe discord, but I haven't seen much (I only "pop in" occasionally and skim for new threads). Specifically, I'm looking for threads that *compare* proposals - and all I'm seeing is threads on individual proposals, ironing out details and technicalities - which is important, sure, but not relevant to me in terms of knowing how proposals compare, and what "public opinion" is favouring. The reason I'm interested in public discussions is that I don't have a particularly strong opinion on the governance model we choose per se, so I'm mostly happy to abstain on a "I trust the rest of the core devs to come up with a sensible decision" basis. **However**, in order to validate that trust, a key part for me is following the discussions, and getting a sense of the overall views of the group. But in this (particularly crucial) instance, I have utterly no sense of what proposals are the front runners, which are considered to have open questions, etc. Up until now, I'd taken that to be because the proposals weren't final, and discussions hadn't really started. But now that the vote is getting close, I'm getting more and more concerned - with no sense of the possible direction of the vote, how can I trust that the decision will be one I can be comfortable with - and how do I influence the direction except by participating in the discussions I've been unable to locate? Currently, I feel like my only option is to abstain and hope - I don't have the time (or knowledge) to review, understand and assess the proposals well enough to make an informed vote, but I have no way of assessing the "expert opinions" of those who do, to allow me to make a broad judgement. Frankly, I feel pretty disenfranchised by the process at the moment. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Sun, 4 Nov 2018 at 00:21, Steven D'Aprano wrote: > But let's be fair to those who have put in the effort to make this work > so far. "Disenfranchisement" is not even close to a fair criticism. Frankly, I'm tired of being picked up on specifics of the wording I used. I felt that "disenfranchised" described how I feel pretty well. If you're saying that my understanding of the word is inaccurate, then fine, I'm happy you know better than me. But I explained my problem in more detail as well as stating the summary version - I can't find context or discussions, I don't have the time to become an expert in all the details[1] but conversely I can't find out what those who *have* investigated the details think, etc etc. It's an important decision, and one I care about, but not one that will massively affect my daily routine, so I want to be involved, but I don't have the means to do so to a level that matches its direct impact on me. If "disenfranchised" isn't the right word for that, then fine, pick your own word and assume I used it. Or assume I just gave the longer explanation and didn't bother trying to offer a one word summary of how I feel. I've explained my concern, I'm not going to debate whether my vocabulary is sufficient to summarise my intent accurately any further. Paul [1] My problem! But a common situation in any voting process - do you expect to understand all the details of international policy before voting in an election? ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Sun, 4 Nov 2018 at 15:25, Steve Dower wrote: > For example, right now, I'm leaning towards 8013, 8010, 8016, 8011, > 8012, 8015, 8014. But since some are still in flux (particularly 8016), > that could change. And my core rationale is basically how likely we are > to be able to fill the roles created by the model. As one example of my confusion here, https://www.python.org/dev/peps/pep-8016/ is currently a 404. So where are you seeing something you can express a preference on? Presumably you're looking at the raw data in github? I have limited time, and I feel like we were promised a deadline after which we could review what was being proposed, and discuss the proposals in a public forum. After that, there would be a vote. But at this point in time, I'm confused about: 1. When the proposals will be finalised and published. 2. Where the discussion(s) will be taking place. PEP 8001 says that the vote will take place in the 2 weeks between 16 Nov and 30 Nov. PEP 8000 states that the following proposals exist: PEP 8010 - The BDFL Governance Model PEP 8011 - Python Governance Model Lead by Trio of Pythonistas PEP 8012 - The Community Governance Model PEP 8013 - The External Governance Model PEP 8014 - The Commons Governance Model PEP 8015 - Organization of the Python community but claims that 8010 and 8012 are placeholders - looking at the PEPs themselves, this seems to be untrue. I'd like to spend some time reviewing the proposals and understanding the options we're being asked to vote on, but I do *not* want to waste time reviewing proposals that are still in flux. How do I know when I can do that? And where do I go to see what *other* people are saying about the relative merits of the proposals? The topics on Discourse seem to be limited to one proposal at a time - so I'm assuming they are thrashing out details (that I don't really care about - I don't have enough of a "high level" feel yet to want to get into that level of detail). I guess I am assuming here that a topic titled "PEP 8013: The External Council Governance Model" is just about PEP 8013, and doesn't include digressions and off-topic subthreads (such as "this is why I prefer PEP xxx over PEP 8013"). I suppose I'm basing that on the fact that the Discourse users are making a point that one of the advantages of Discourse is that threads don't ramble like mailing lists do. In reality, I'm suspicious - it seems to me that human nature is such that discussions *do* digress, and go off topic. But again it's about time - if Discourse is just as much a bunch of wide ranging discussions as the mailing list is, I don't have time to follow all of Discourse as well as all of the lists I follow, and I don't have the time to learn how to manage and prioritise on Discourse (or at least, whatever time I do have that I could use for that, I'd rather use to better understand the governance proposals, as those are more important!) In the end, I accept that "I don't have enough time to do a good job" is something I have to accept and decide whether I abstain from the vote, or skim and vote as best I can based on that. That's something I can't expect help in deciding - but a little more clarity on what's happening with the process would make it a lot easier for me to make that decision myself. Anyhow, this is probably a bit off-topic again. I don't know whether anyone thinks I'm offering anything new here - I feel like I'm explaining my concerns from another perspective, but maybe all that's coming across is me going on about the same things over and over. If so, I apologise. I'll do my best to assume that I've said my piece now, and if nothing gets better then I'm just going to have to deal with it, as my views have been heard and that's all I can expect. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Mon, 5 Nov 2018 at 19:11, Brett Cannon wrote: >> Anyhow, this is probably a bit off-topic again. > > Yes, but that's a drawback to mailing lists in my opinion and it's hard to > avoid. :) I did consider what I would have done on Discourse, and came to the conclusion that I would have done exactly the same - I've no idea how Discourse would help with a "here's some things I thought of that I felt needed saying while reading this thread" post. Obviously I could move the reply to a new topic, but I could just as easily have changed the subject in the mailing list. So without meaning to ignore your smiley, I don't think it's really a fault with mailing lists, just with how people discuss things ;-) Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Mon, 5 Nov 2018 at 19:11, Brett Cannon wrote: >> I'd like to spend some time reviewing the proposals and understanding >> the options we're being asked to vote on, but I do *not* want to waste >> time reviewing proposals that are still in flux. How do I know when I >> can do that? > > I think the original point to this thread was to figure that out. My > assumption is that if we don't change dates then all 801X PEPs will forcibly > go into "final" status and not be updated short of spelling mistakes or > clarifications that were simply overlooked -- i.e. no semantic changes -- on > November 15. Hmm, so voting opens immediately after the PEPs are finalised? No discussion/debate period before that? Maybe I misunderstood, I'd assumed that this would be more similar to an election process, with a period of canvassing support and/or debating the strengths and weaknesses of the proposals, leading up to a vote. OK. I can't say I *like* that, but if that's what's happening then that probably explains some of my confusion. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
I'm going to quote multiple people here and respond to various comments at once. It's way harder doing so than it would have been in Discourse, so I'm sort of proving that for myself (but having said that, I was already aware of, and fine with, the idea that Discourse does stuff like this better - it's simply that I don't have the time right now to learn a new bit of software and adapt my workflow to its approach). On Mon, 5 Nov 2018 at 19:34, Donald Stufft wrote: > I don’t think there is anything stopping people from doing that right now > (and honestly, right now seems like the *right* time to do that if it’s going > to happen, so that the proposals can evolve based on any discussion that > comes out of that). Waiting until the proposals are set in stone seems like a > less useful implementation of that idea. Well, in my case I specifically don't want to end up commenting on things that have changed and my understanding is out of date. That's a common problem with PEP discussions, and one that I don't feel would be helpful here. But agreed, if you see it as "wait until things are set in stone", it sounds worse. Seeing it as "waiting until things are stable" sounds more reasonable (at least to me) while still meaning essentially the same ;-) > I suspect the reason that people aren’t doing that, is just nobody has > started that discussion for one reason or another. I suspect that what those reasons are would be interesting. I wonder how high "because I didn't think the proposal was finished yet" would come? It's what's stopping me (although I tend to comment on threads started by others more than starting my own, so I'm not a good example), On Mon, 5 Nov 2018 at 19:37, Brett Cannon wrote: > Hopefully the above explanation assuages your worries, otherwise I don't > understand your worries. To an extent, yes. My main worry is that there won't *be* the sort of discussion I'm hoping for. I like to have a sense of what the broad consensus is on a proposal before making my own final decision, and at the moment there's no discussion that I've seen that gives me that sort of sense. If that remains the case over the 2 week voting period, it'll be a little late by that point. And it's not obvious to me how I could *start* such a discussion - "so how are people going to vote?" isn't a particularly subtle opening. This tends to be "solved" (in some sense) in political debates by the various parties trying to persuade people to vote for them. That's not happening here, and I think I'm just finding that unnerving (because the whole process has a feel of a political debate to me). Anyhow, I guess it's just me expecting something from the process that it's not. And that's for me to deal with. On Mon, 5 Nov 2018 at 19:49, Tim Peters wrote: > In the absence of trying it for yourself, you could, e.g., look for > what the people who designed the system had in mind. The lack of a > fully threaded view in Discourse was 100% intentional, not due to, > e.g., laziness, or lack of time or skill. > > Here's a start: > > https://blog.codinghorror.com/web-discussions-flat-by-design/ > > I'm not necessarily endorsing those views, but I did take the time to > try to find out _why_ they did what they did. It wasn't capricious. > There are things I do and don't like about Discourse, but _which_ > things are still changing for me over time ;-) Thanks, Tim. That link is definitely something I'll read up on. My impression has always been that every part of Discourse's design was carefully thought through, but I hadn't seen any specifics before. As I say above, though, it's not that I don't intend to try Discourse (and indeed, I know there are many things I expect to like about it) - it's simply that I don't have time right now. I'm twitchy about that fact because I *want* to follow the discussions on the governance issues, but I haven't worked out an effective way to do so with the time I have available right now. (No need for replies to any of the above. I appreciate all of the comments and anything I'm still concerned about is something I'll have to work out for myself). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Thu, 15 Nov 2018 at 12:55, M.-A. Lemburg wrote: > > I find it rather unusual that we are pushed to vote on PEPs > which will just have been finished in writing tonight. > > Shouldn't people who were not involved in the individual creation > processes at least get two weeks to review the final work > to make up their mind before entering a voting period ? That's probably the thing that bothers me most, as well. That and the fact that once I've cast my vote, I can't change it - so I really have to defer voting until the last minute, in case someone comes up with a compelling argument for one proposal that I hadn't thought of. I made a deliberate choice *not* to get involved in the discussions while the proposals were being prepared, because I find it far too easy to get an impression of a proposal from an early draft and then misjudge the proposal by not updating my views once it's updated. I don't want to do that with this decision, as it's pretty important (!) and so I've held off reading any of the proposals until they are announced as final. And yet, it looks like once they are announced, there's a possibility that people will start voting and then excuse themselves from discussion (because once you've voted, there's no point discussing any further). I can read them, but may not have anyone to discuss them with once I've done so... That doesn't sound like an ideal way of reaching consensus. Having said all that, it's not like the decision making process will be changed at this point, so I think that we're going to have to accept it, flaws and all, as it stands. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Timeline to vote for a governance PEP
On Thu, 15 Nov 2018 at 18:55, Brett Cannon wrote: > OK, so it seems you're unhappy that you only have a day to vote since you > can't change your vote ... [...] > ... but then you don't like that people can vote over two weeks because you > don't want discussions to occur while people can vote to force them to > participate in discussions? I might be missing something, but these two > issues seem contradictory, especially since we can't exactly force people to > not talk about this while voting is open. :) No, I'm uncomfortable with the discussion period overlapping the voting period, because the fact that you can't change your vote means that once someone votes, there's no incentive to continue discussing. But I accept that it's how it's going to be, I'm not arguing for any change here at this late stage. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] A plea to stop last-minute changes to governance PEPs
On Mon, 19 Nov 2018 at 11:24, Nathaniel Smith wrote: > Thanks for raising this. It's an important issue and one where I've > been struggling too. > > I'll put my conclusion first. My suggestion: > > - We do allow changes to the PEPs until the actual voting starts, but > not afterwards > - We leave it up to the PEP authors' judgement what changes they want to make > - The PEP authors will work together to maintain a single shared > changelog summarizing every change that's made to the PEPs after Nov. > 16, no matter how trivial, and including links to the relevant commits > so you can easily see the actual text > - We'll include a link to this changelog prominently in the voting > instructions etc. > > This is easy to implement, avoids messy subjective judgements about > which changes are "too big", allows the PEPs to be tweaked and > clarified through the review period, and would mean that so long as > you read the PEPs at least once during the review period and then > check the changelog before voting, you're guaranteed that you won't > miss anything. I agree, this is a really difficult question to get right. My feeling, however, is that the PEPs that are having the most trouble with this are the ones that are trying to pin down too much detail. Sure (to pick a random example), it's ultimately going to be important that a council have a clear idea of how they reach agreement on banning a core developer, should that situation come up. But is it really going to be so critical to establish that detail *right now* that someone would change their vote **to a completely different governance model** if the number of votes was set at 3 or 4? And is the proposal explicitly denying us the chance to change that number based on experience going forward?[1] I realise this is precisely the point you made about subjective judgements, but I think it needs to be taken in context. I have a maximum of 7 proposals to choose from (6 if Steve withdraws his). I'm interested in the overall "shape" of the proposal (leader or group who decides vs community voting for example) and the "tone" (is it concerned with pinning down lots of details, does it assume we'll trust each other to work in good faith, is it bureaucratic, is it well-established or novel, etc). The sorts of changes you're talking about in the examples you give mostly leave me with a feeling of "this proposal is prone to getting bogged down in details, it's overspecified", and that's what will affect my vote rather than the actual detail being debated[2]. > It's possible PEP 8016 is particularly prone to this because a design > goal was to be small and explicit enough to encourage > nitpickingdetailed review, but I'm not just suggesting this > because "my" PEP has special needs. I'd characterise this more as "PEPs that try to specify too much detail are prone to this because they encourage 'detailed review'"... ;-) > - Steve Dower is considering withdrawing PEP 8014 entirely [4], which > if it happens would be a major substantive change to PEP 8014 that > voters would want to know about! Knowing about it - definitely. But more importantly, I'd like to know *why*! If Steve no longer considers his proposal worth voting for, what is his logic, and what does he consider a reasonable alternative for people who *did* want to vote for it? Personally, I'm not that worried as that wasn't one of my preferred proposals, but I do think that if you have created a proposal, you have a certain level of responsibility to the people who liked it to give them information on what you view as the "migration path" from what they voted for to where you are now (and "not being able to vote for it" is a pretty extreme case of that!) > - In the course of a discussion that Paul Moore started about > processes for promoting core devs, I realized [5] that there's (what > feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about > how much power the Technical Leader or Trio would actually have – > specifically I'd been assuming one thing, but realized that the texts > actually don't say either way. I hope Barry and Mariatta will clarify > what they intended before the vote starts. No matter which way they > clarify things, it may feel like a substantive change to some people, > depending on how they read it originally. And yet, I hope they don't, as a key point for me about their proposals is that they *don't* try to specify everything up front, but rather they allow for the leader/council to make judgements as time goes on. If you feel that as a result their proposals are underspecified, by all means vote for something else. > In this la
Re: [python-committers] A plea to stop last-minute changes to governance PEPs
On Mon, 19 Nov 2018 at 16:32, Steve Dower wrote: > FWIW, I'm thinking about withdrawing it because PEP 8016 captures my > highest priorities (specifically, core developers don't have a monopoly > on decision-making skills, and don't apply unnecessary constraints on > whoever leads in this PEP). The rest of my proposal is just enough > detail to be functional, but I'm not really wedded to it, so if there's > an alternative that mirrors the core values then I'll tell people to go > vote for that instead of mine. Interesting. I considered the distinguishing feature of your proposal to be that it explicitly *excludes* core devs from the council (to the extent that you call out that feature as what distinguishes it from 8011). I wasn't keen on that, so I never really got much beyond that aspect of your proposal to be honest - so it's weird to me that you don't think it's particularly significant. But thanks for the clarification. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
On Mon, 4 Feb 2019 at 16:20, Ernest W. Durbin III wrote: > I can open a PR to 8100 with detailed results if no objections are heard. +1 Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] [Steering-council] Re: Can we choose between mailing list and discuss.python.org?
On Tue, 12 Feb 2019 at 12:38, Nick Coghlan wrote: > > On Victor's original question, the Discourse experiment has been successful > enough that I don't see a problem with the committers mailing list going > essentially "announce only". I agree with Barry that going further than that > would require a PEP, but Discourse is bad enough for announcements that I > don't see much reason to do that. My feeling is that the pace of discussions is slightly different than on the list. See Terry's comment "Otherwise, we would depend on people happening to drop by and notice the vote" - this is another aspect of the "bad for announcements" aspect of Discourse, things can often sit unnoticed for a while due to the fact that Discourse is less of "push" medium and more of a "pull" one (notifications notwithstanding). I think people still need a little time to get used to that change of pace, so discussions don't get assumed to be concluded too soon. But otherwise, yes, for python-committers I think it's worked out well. I do *not* think we know yet whether that will be the same for other groups, and I am worried that monitoring things on a per-category basis may be both necessary and uncomfortably difficult once there's more traffic. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Can we choose between mailing list and discuss.python.org?
On Tue, 12 Feb 2019 at 22:00, Antoine Pitrou wrote: > Here is a 161-message Discourse thread (at the time of this writing): > https://discuss.python.org/t/pep-517-backend-bootstrapping/789 As someone directly involved in that discussion, with a strong need to understand all of the points being made, that's a great example of both the benefits and the flaws of the discourse model. > I know I can browse easily through a 161-message mailing-list or > newsgroup thread using a traditional threaded view, read what I want, > come back later to read the rest, etc. But Discourse's linear > presentation pretty much kills that ability. It doesn't even allow > *seeing* the structure of the discussion. I don't use a threaded mail client (I use gmail's web interface) so I don't get any of the benefits of threading from a mailing list. So to that extent, Discourse's lack of threading is no different for me, and shouldn't affect my ability to follow the discussion. But it *does*, and in practice, it's substantially worse than a traditional mailing list. (Note: this is only a comment about long, complex discussions like this one, for shorter threads the Discourse view is fine). The problem isn't, IMO, so much the lack of threading as the lack of *context*. We're all used to (and frustrated by) mailing list threads that are 90% quoted text. But Discourse goes to the other extreme, of having very *little* context - no thread structure, a tendency towards minimal quoting, and an *extremely* non-obvious "reply" UI (you can "reply" to any message, or to the thread as a whole, but the distinction is almost invisible, and doesn't support "replying to" *part* of a long comment. Also, the lack of any "mark unread" functionality makes it easy to lose track of where you're up to - I popped into that discussion to check some facts for this post, and found myself needing to read a number of quite detailed messages, as otherwise they would no longer show as "unread" for me, and I'd risk losing my place in the discussion. I know there are bookmarks, but they don't match my mental model which is "I saw these posts, but haven't *read* them". Anyway, I remain generally happy with Discourse for lower-traffic lists that have relatively short threads. Medium sized ones (like packaging replacing distutils-sig) I'm not certain about yet, but I think "probably no worse" is as far as I'd go right now. For groups like python-dev or (worse still) python-ideas I feel like they would be a terrible fit. There's also the interaction effect - high traffic in one category pushes out information about what's new in *other* categories, and there's no "list of categories with a count of unread messages" view to mitigate it. tl;dr; I don't think discourse scales particularly well to long, complex discussions, but I think it's less about threading than about other aspects of the UI. At the end of the day, managing long, complex discussions is *hard* and I think Discourse is optimised for different parts of the spectrum than mailing lists. But while the day to day volume of traffic might be shorter threads, the massive, complex, rambling threads are the lifeblood of Python development (much as we might all hate them ;-)) and we need to be cautious about making decisions for those cases based on evidence from other, simpler, situations. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Can we choose between mailing list and discuss.python.org?
On Wed, 13 Feb 2019 at 19:56, Steve Dower wrote: > > On 13Feb2019 1112, Brett Cannon wrote: > > > > > > On Wed, Feb 13, 2019 at 2:55 AM Paul Moore > <mailto:p.f.mo...@gmail.com>> wrote: > > > > On Tue, 12 Feb 2019 at 22:00, Antoine Pitrou > <mailto:anto...@python.org>> wrote: > > > Here is a 161-message Discourse thread (at the time of this writing): > > > https://discuss.python.org/t/pep-517-backend-bootstrapping/789 > > > > As someone directly involved in that discussion, with a strong need to > > understand all of the points being made, that's a great example of > > both the benefits and the flaws of the discourse model. > > > > > > Can I ask if that entire thread is on topic, or is there a reasonable > > point in that discussion where side conversations could have been broken > > off into a separate topic(s)? When email threads tend to reach that > > length there have been side discussions that could have become their own > > topic if someone thought to change the subject and Discourse allows for > > having an admin break posts off at any point and I'm curious if it would > > have been helpful and people simply didn't think about it (I know I > > don't always think of it immediately yet). > > My feeling (as I followed the entire discussion from the start) is that > the side discussions all tied back, rather than diverging permanently. > So at best it would be "you 2-3 go and discuss this part separately and > come back when you agree", which as we know is often followed up by "you > other 2-3 re-discuss everything they already discussed since you weren't > part of the side discussion". Precisely this. I don't know *how* I would have split off a separate sub-thread in Discourse if needed (it's easy enough in email by changing the subject, I presume it's not much harder in Discourse?) but I don't think there was any obvious point at which that would have helped rather than hindering. And as the goal of the whole thread was to reach a consensus on a change to PEP 517, if we *had* split things up, there would have been the problem of pulling the subthreads together again later. > So in this case, I don't think it would have benefited from being split > out. In fact, I think it worked best in the linear form because when > someone (typically either Paul or Thomas) declared a summary, it > basically forced all the branches to converge. I can't speak for Thomas, but I think I would have done exactly the same in mailing list form. As I said elsewhere, I don't think the difficulties are particularly about linear vs threaded forms. > It's a long discussion because it has no clear answer and the concerns > are on the level of "what weird things will the entire world do if we > offer this", which can't be tested. As far as asynchronous, online-only > options go, I'm not convinced that any other approach would have worked > better. When trying to do those summaries, and trying to catch up now (I've been unable to follow the discussion closely for a week or two) I'd say the Discourse format made it a bit harder. But that's *not* linear vs threaded, it's more about things like how quoting works and how comments are linked back to what they are referring to. (On the other hand, rich text, and not having to deal with email mangling of quoting structure, help a lot). Big discussions like this one are hard *whatever* medium is used. I don't think Discourse is *bad*, I just don't think it's noticeably *better* than email. And my major concern is that I don't think Discourse will scale well to high-traffic categories with substantial numbers of this sort of discussion (and worse, I think the existence of high-traffic categories could have a detrimental effect on more moderately-sized ones). But I think it's too early to tell for sure. Back to the original question, about the committers list: 1. I think the committers traffic is the right sort of size for Discourse, and works OK. 2. I think Discourse is bad for "quick turnaround" things like votes, because it's too easy for people not to see the discussion until it's too late (and no, I don't think formally posted voting periods will help much there). It *may* be possible to alter people's expectations to make the slower turnaround acceptable - it's not like (say) a core developer vote has to be resolved particularly quickly, after all. 3. I don't think any conclusions we draw based on the committers category should be assumed to scale to larger lists (whether in terms of number of messages, number of participants, length or complexity of threads, or anything else). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Can we choose between mailing list and discuss.python.org?
On Wed, 13 Feb 2019 at 20:50, Antoine Pitrou wrote: > Apparently you're saying that just because you can't/don't want to use a > more appropriate tool, other people shouldn't be able too. That sounds > ridiculous to me. Use an inferior tool if you want, but don't force > other people to. That;'s a common complaint in these discussions and it has some merit. However, Gregory also said (in a very relevant comment that you unfortunately omitted): >> If we want to enforce an interface on people, IMNSHO that is what something >> like Discourse is for The question here is fundamentally, whether we do want to enforce an interface on people. If we do, then there will be some losers (people with effective and highly tuned email workflows, like yourself) and some winners (for example, people like me who cannot in practical terms use anything other than a web interface). The judgement is whether the benefit to, and number of, the winners outweighs the disadvantages to, and the numbers of, the losers. (And the more abstract question of whether restricting users' choice is a good or a bad thing, but I'm going to pass on that). I don't know the answer. As a "winner", my feeling is that the advantage to me is marginal for longer more complex discussions, and reasonable for shorter discussions. So I don't feel that I'm much of a data point. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Paul Ganssle got the bug triage permission
Congratulations, Paul, and welcome. Glad to have your help! Paul On Thu, 14 Feb 2019 at 17:04, Carol Willing wrote: > > Welcome Paul :D > > Looking forward to working with you more. > > > On Feb 14, 2019, at 8:27 AM, Victor Stinner wrote: > > > > Hi, > > > > Paul Ganssle just asked me to close a bug which he fixed. Instead, I > > just gave him the bug triage permission :-) > > > > Paul is the author of dateutil: > > https://github.com/dateutil/dateutil > > > > He is fixing more and more datetime issues for longer than 1 year, > > including some tricky and very old issues: > > https://github.com/python/cpython/commits?author=pganssle > > > > For example, he implemented .fromisoformat() which was a long awaited > > feature: > > https://docs.python.org/dev/library/datetime.html#datetime.date.fromisoformat > > > > Recently, he got the approval to change how datetime subclasses are > > handled, feature very useful for third-party libraries written on top > > of datetime: > > https://github.com/python/cpython/commit/89427cd0feae25bbc8693abdccfa6a8c81a2689c > > > > I'm happy to see him helping Alexander Belopopsky (current datetime > > maintainer), on maintaining datime, who is more busy these days. By > > the way, they met each other ;-) > > > > I sent Paul instructions how to triage bug and links into the devguide. > > I asked him to ask me before closing a bug. > > > > Congrats Paul ;-) > > > > Victor > > -- > > Night gathers, and now my watch begins. It shall not end until my death. > > ___ > > python-committers mailing list > > python-committers@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@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Welcome Stefan Behnel to the team!
Welcome! On Mon, 8 Apr 2019 at 21:07, Antoine Pitrou wrote: > > > Welcome Stefan and Stéphane ! > > > Le 08/04/2019 à 22:04, Brett Cannon a écrit : > > > > > > ___ > > python-committers mailing list > > python-committers@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@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Welcome Stefan Behnel to the team!
Welcome, Stefan, nice to have you with us :-) On Tue, 9 Apr 2019 at 06:53, Stefan Behnel wrote: > > Thanks, everyone, for bringing me in! > > I don't have much to add to what was written here about myself recently, > except that I'm happy to join, and flattered by the result of the vote. I'm > currently working on some XML issues for the stdlib, I'll see where that > gets us. > > There were a couple of counter-votes in the poll, and that's perfectly ok, > but if anyone wants to talk to me about them in private, here's my e-mail > address. > > Hope to meet some of you at EuroPython this year! > > Best, > Stefan > > ___ > python-committers mailing list > python-committers@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted
On Wed, 15 May 2019 at 09:51, Antoine Pitrou wrote: > > On Tue, 14 May 2019 18:11:14 -0700 > Barry Warsaw wrote: > > > As the BDFL-Delegate for PEP 581, and with the unanimous backing of the > > rest of the Steering Council, I hereby Accept this PEP. > > For future reference, is it possible to post the Steering Council's > reflection and rationale on the PEP? Also, is there an archive of the discussions anywhere? The PEP says discussions happened on Zulip, but I don't follow that and I don't know where I can find an archived copy of the discussions. It's not as if I'm going to object to the PEP (I'd have participated in the discussions if I had a strong opinion) but I am curious. Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted
On Wed, 15 May 2019 at 15:56, Victor Stinner wrote: > > Hi Paul, > Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit : > > Also, is there an archive of the discussions anywhere? The PEP says > > discussions happened on Zulip, but I don't follow that and I don't > > know where I can find an archived copy of the discussions. > > Well, the PEP has been discussed a lot at many places since May 2018. Thanks for all of these. I appreciate the time you took locating them for me. But I do have to say that I still can't really follow any useful "thread of discussion" - it all seems very fragmented, and it's difficult to see the progress towards consensus. Maybe that's just because I'm too used to mailing lists :-) > The PEP 581 has been (first?) discussed at the Language Summit which > was part of Pycon US 2018 (May 2018). Was that written up, or is it all just from people's memories by now? > https://github.com/python/peps/pull/681/ Ah - I don't really follow this sort of PR discussion, as the github emails don't tend to have sufficient context on what's being said, so I (mostly) gave up a long time ago. Also, I tend to assume that discussions on PRs are mostly about details of wording, and substantive changes will be dealt with in a wider forum. I wonder if I should be following PRs on the PEPs repository more closely...? > Multiple threads on Discourse: > > https://discuss.python.org/t/move-pep-581-discussion/873 > https://discuss.python.org/t/pep-581-using-github-issues/535 > https://discuss.python.org/t/what-are-next-steps-for-pep-581/864 > https://discuss.python.org/t/pep-process-after-pep-8016/558/4 > > Thread on python-dev: > > https://mail.python.org/pipermail/python-dev/2019-March/156626.html > > Threads on python-committers: > > https://mail.python.org/pipermail/python-committers/2018-May/005428.html > https://mail.python.org/pipermail/python-committers/2018-June/005506.html > https://mail.python.org/pipermail/python-committers/2018-July/005657.html I saw these, but didn't get much of a sense of progress towards agreement. Again, maybe just because they were lots of fragmented threads and locations. > Discussion on Zulip Chat: > > https://python.zulipchat.com/#narrow/stream/130206-pep581 I can't see this without logging in :-( > The Steering Council discussed it internally as well: > > https://github.com/python/steering-council/blob/master/updates/2019-04-26_steering-council-update.md I did see that, I was more wondering what led to that decision (whether it was a general consensus from the core devs that it was a good move, or mainly the SC's own view that prevailed). > The PEP 581 and 588 have been discussed at the Language Summit which > was part of Pycon US 2019 (2 weeks ago). Again, has there been any write up of that (yet)? As I say, I don't object to the decision, I'm more just trying to better understand the process of being involved under the new regime of the SC, combined with multiple fragmented forums for discussion. It feels a lot harder these days to keep track of all the discussions/decisions going on. But maybe that's a good thing - only people with a genuine interest get involved, and I can spend less of my time reading mailing lists! :-) Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Azure build operations
On Tue, 21 May 2019 at 19:10, Antoine Pitrou wrote: > > Hello, > > How can I restart a failed build on Azure? > https://dev.azure.com/Python/cpython/_build/results?buildId=43161&view=logs&j=18d1a34d-6940-5fc1-f55b-405e2fba32b1 You can close and reopen the PR, but that restarts every build. I think there should be a way to restart an individual build, but it requires certain rights. I just checked, and I don't have the right to do so, and I'm afraid I don't know who gives out those rights (or even if it's something that we do give out to individual core devs). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Welcome Paul Ganssle to the Python core team!
Congratulations, and welcome Paul! On Sun, 16 Jun 2019 at 20:12, Brett Cannon wrote: > > Assuming I didn't mess up, Paul should be set up appropriately at this point. > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/YGHU7QPBTIMAU5X5K3PGJMHQQJ2XCNLY/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/3WFRUGMDG2CPAOKKNOIJJUMGH6D45FLK/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Cleaning up the historical list of core developers
On Thu, 4 Jul 2019 at 18:53, Brett Cannon wrote: > > > Did not commit/author beyond a 3 month time span from first > > > commit/authorship to last commit/authorship and their last commit > > > was more than two years ago (helps cover people we don't have good > > > records for in terms of sprints or GSoC who never got involved) > > > > > > Hmm... I may be a bit dense, but I don't understand that sentence :-S > > > Let's say someone made all of their commits from 2015-07-04 to 2015-10-04 > (and when I say "commits" I mean committing or authoring in git terms). That > means they committed over a span of less than 3 months over the entire > history of the cpython repo and that the last commit was more than 2 years > ago. In that instance I'm suggesting we drop the person as chances are they > were probably a GSoC student or a sprinter who tried things out but quickly > walked away. > > Or put another way, I'm arguing that if you spent less than 3 months making > commits to cpython over two years ago you were probably not someone who got > promoted to being a core developer through the normal promotion process. I may fall under this category, as I don't actually commit much to the cpython repo. But I would very much like to continue being considered as a "core developer". As I understand it, my saying so here should be sufficient for that to happen (I will say so again when the actual lists come out, if it turns out I'm right). If there's anything else that I'd need to do in order to stay on the list, can it be clarified what that is? Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/FZWKDPQZ3JESDV5PEDILECK62JAMBI4U/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Welcome Abhilash Raj to the Python core team!
Welcome, Abhilash! Great to have you on board :-) Paul (BTW, I didn't see an announcement of the closing of the vote and the final result on Discourse - did it get announced there?) On Tue, 6 Aug 2019 at 23:03, Barry Warsaw wrote: > > Congratulations and welcome Abhilash! Thanks Brett for setting him up, and > thanks everyone who voted. > > -Barry > > > On Aug 6, 2019, at 14:19, Brett Cannon wrote: > > > > Assuming I didn't mess anything up, Abhilash is now set up! > > ___ > > python-committers mailing list -- python-committers@python.org > > To unsubscribe send an email to python-committers-le...@python.org > > https://mail.python.org/mailman3/lists/python-committers.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-committers@python.org/message/7DCE4DR7FNLAWXQSNEBRSGOMFOVGKK3F/ > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/QM25LIFW43T6ODHEK5BK75NMCHAGQO3G/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/636ZYTD3JZ6YMDHAENATP2UW5UZAGVBN/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: MSDN subscriptions/renewals
I sent my info to br...@python.org, which was the sender address on the original email I got. On Fri, 9 Aug 2019 at 05:01, wrote: > > Where you I send the info? I'm not sure which email address you're using. > > Raymond > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/MET3V6X6QO4NEGBAZZR4T3DLZSOAFSF2/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/VYDPMAFRST7TSM7GXBWLTAZUEBM5PYVH/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues
I have to say that I agree with Raymond here. I don't think that an issue tracker is a good way to collect this sort of feedback. To be honest, I don't feel that there's going to be much scope to address the sorts of concerns being raised here, so I'm not clear how much value there will be in the discussion, ultimately, but I do think that having a single conversation/thread/topic that covers the "big picture" is important, as for some people the problem is going to be an accumulation of small problems, rather than any one big showstopper. And tracker items have, in my experience, a tendency to dilute the impact of that sort of accumulation. It seems like the idea here is that we handle the discussion on how to use the github tracker for Python issues, by using a github tracker for the plan. Does that not result in a problem, because people uncomfortable with the github tracker will be uncomfortable with the means they are required to use to express that discomfort, and so their voice won't get heard? Personally, I have a workflow that works (just about) for me, for handling any given github issue tracker (filtering email notifications to a dedicated folder for the tracker) but that method does not scale very well, and it *definitely* doesn't work for following trackers on an adhoc basis. So I'm not going to easily be able to follow discussion on the tracker-for-discussing-issues-with-the-proposed-cpython-issue-tracker (ERROR: Recursion depth exceeded ;-)) So I guess I give up and leave the decision to others. In my case, not that big of a deal, as I don't use the current tracker that heavily - but if someone like Raymond takes that view, that's (IMO) quite a lot more serious. Paul On Sun, 13 Oct 2019 at 06:20, wrote: > > Are you saying that this whole thread of issues will be ignored unless we all > go to another forum, post a dozen separate issues, and recreate all of the > discussion that already these threads? > > That doesn't seem reasonable to me for several reasons: 1) it is unlikely > that the full thread content would survive the forum transfer, so that some > important aspects of the conversation will be lost, 2) some of us have very > few clocks cycles available to allocate because discussion threads and actual > core development, 3) this is outside our historical norm -- we normally do > PEP level discussions on the lists rather than in many separate issues, 4) > the separate issue approach (particularly if it is in core-workflow) won't > have much visibility or participation for the folks who currently do most of > the work on the tracker, and 5) having separate issues tends to obscure the > big picture of how much functionality will be lost as a result of the > migration and how much disruption will be caused by breaking existing user > conversations and losing searchable history. > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/2HWYHURO7XETBZO7YR4V6JDWX3FA2OA5/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/C2RRCOM2XN2D77RWCID72YDOLN5V33I5/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Possible bug in voting system ? (was: Re: Reminder to vote for the 2020 Steering Council)
On Tue, 10 Dec 2019 at 21:07, Senthil Kumaran wrote: > > > As it turns out I was removed from the list of voters by the above > > script, without being asked, and would like to be added back again. > > I support this, and I hope this can be rectified for this election period > itself. +1 from me as well. Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/DRI5AJFAX3MMHOJWPJLEV2ELLJCJPGJC/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Welcome Kyle Stanley to the team!
Welcome, Kyle! On Wed, 15 Apr 2020 at 01:47, Brett Cannon wrote: > > And just in time for the language summit! :) > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/6MD34LIFZ4CKAQJ2IEGQBOLTX5KFYTGM/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/GNQTLVAAHD2VIAKLE3ZQQ5BQAVQIJ4XT/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Performance benchmarks for 3.9
The performance figures in the Python 3.9 "What's New" (here - https://docs.python.org/3/whatsnew/3.9.html#optimizations) did look oddly like a lot of things went slower, to me. I assumed I'd misread the figures, and moved on, but maybe I was wrong to do so... Paul On Wed, 14 Oct 2020 at 14:17, Pablo Galindo Salgado wrote: > > Hi! > > I have updated the branch benchmarks in the pyperformance server and now they > include 3.9. There are > some benchmarks that are faster but on the other hand some benchmarks are > substantially slower, pointing > at a possible performance regression in 3.9 in some aspects. In particular > some tests like "unpack sequence" are > almost 20% slower. As there are some other tests were 3.9 is faster, is not > fair to conclude that 3.9 is slower, but > this is something we should look into in my opinion. > > You can check these benchmarks I am talking about by: > > * Go here: https://speed.python.org/comparison/ > * In the left bar, select "lto-pgo latest in branch '3.9'" and "lto-pgo > latest in branch '3.8'" > * To better read the plot, I would recommend to select a "Normalization" to > the 3.8 branch (this is in the top part of the page) >and to check the "horizontal" checkbox. > > These benchmarks are very stable: I have executed them several times over the > weekend yielding the same results and, > more importantly, they are being executed on a server specially prepared to > running reproducible benchmarks: CPU affinity, > CPU isolation, CPU pinning for NUMA nodes, CPU frequency is fixed, CPU > governor set to performance mode, IRQ affinity is > disabled for the benchmarking CPU nodes...etc so you can trust these numbers. > > I kindly suggest for everyone interested in trying to improve the 3.9 (and > master) performance, to review these benchmarks > and try to identify the problems and fix them or to find what changes > introduced the regressions in the first place. All benchmarks > are the ones being executed by the pyperformance suite > (https://github.com/python/pyperformance) so you can execute them > locally if you need to. > > --- > > On a related note, I am also working on the speed.python.org server to > provide more automation and > ideally some integrations with GitHub to detect performance regressions. For > now, I have done the following: > > * Recompute benchmarks for all branches using the same version of > pyperformance (except master) so they can >be compared with each other. This can only be seen in the "Comparison" > tab: https://speed.python.org/comparison/ > * I am setting daily builds of the master branch so we can detect performance > regressions with daily granularity. These >daily builds will be located in the "Changes" and "Timeline" tabs > (https://speed.python.org/timeline/). > * Once the daily builds are working as expected, I plan to work on trying to > automatically comment or PRs or on bpo if > we detect that a commit has introduced some notable performance regression. > > Regards from sunny London, > Pablo Galindo Salgado. > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/G3LB4BCAY7T7WG22YQJNQ64XA4BXBCT4/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/XHRZO6MFHFJETR54TSIXBMLFDJOXS3Z4/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Hai Shi got the bug triage permission
On Fri, 13 Nov 2020 at 15:38, Victor Stinner wrote: > > Congratulations Hai Shi! Congratulations Hai Shi, and thanks for all the work you've been doing! Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/QTQGJSCZXGZHQC3LJSGAN37HNIIKKLHB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Python Core Developer Status Inquiry
I'm pretty sure I saw an email from Steven D'Aprano on this list recently. On Wed, 18 Nov 2020 at 15:44, M.-A. Lemburg wrote: > > I've sent a reminder to these core devs: > > Alexandre Vassalotti > Amaury Forgeot d'Arc > Armin Ronacher > David Wolever > Eli Bendersky > Jack Diederich > Jack Jansen > Jeremy Hylton > Kurt B. Kaiser > Lars Gustäbel > Martin Panter > Matthias Klose > Meador Inge > PJ Eby > Philip Jenvey > Sjoerd Mullender > Steven D'Aprano > Thomas Heller > Trent Nelson > > who have not replied yet. > > The deadline is Nov 25 AoE, when I'll merge the PR with the updates: > https://github.com/python/voters/pull/30 > > Thanks. > > On 11.11.2020 22:00, M.-A. Lemburg wrote: > > FYI: I have sent out the Python Code Developer status inquiries to > > these core developers, which have not committed to the CPython > > Github repo in the last two years and for which we don't have > > a status answer using the new inactivity reply feature in the > > voter roll script yet: > > > > Alex Martelli > > Alexandre Vassalotti > > Amaury Forgeot d'Arc > > Armin Ronacher > > Christian Tismer > > David Malcolm > > David Wolever > > Doug Hellmann > > Eli Bendersky > > Fred Drake > > Georg Brandl > > Hynek Schlawack > > Jack Diederich > > Jack Jansen > > Jeremy Hylton > > Kurt B. Kaiser > > Lars Gustäbel > > Marc-André Lemburg > > Mark Hammond > > Martin Panter > > Matthias Klose > > Meador Inge > > PJ Eby > > Petri Lehtinen > > Philip Jenvey > > Sandro Tosi > > Sjoerd Mullender > > Steven D'Aprano > > Thomas Heller > > Tim Golden > > Trent Nelson > > > > For some more background, please have a look at the ticket > > https://github.com/python/voters/issues/16 and the associated > > PR https://github.com/python/voters/pull/25 > > > > I used the email addresses from the python-core.toml file and > > will collect replies in the next two weeks and collect them > > in this PR: https://github.com/python/voters/pull/30 > > This can then be merged before creating the final voter roll > > for the election. > > > > PS: I attached the mail merge template I used for the emails below. > > > > Cheers, > > > > > > ___ > > python-committers mailing list -- python-committers@python.org > > To unsubscribe send an email to python-committers-le...@python.org > > https://mail.python.org/mailman3/lists/python-committers.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-committers@python.org/message/O3CC7U2ERJLUCJRE7UOE7GIXME5VK3LL/ > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Nov 18 2020) > >>> Python Projects, Coaching and Support ...https://www.egenix.com/ > >>> Python Product Development ...https://consulting.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 >https://www.egenix.com/company/contact/ > https://www.malemburg.com/ > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/4IF2GAKPJSZWCDRQUDDVHULGLU4TDDDQ/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/HLZM7OXOIPYMDL74DGUCYZ3SOEBYCE24/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: PEP 563 and Python 3.10.
On Wed, 21 Apr 2021 at 12:05, M.-A. Lemburg wrote: > Perhaps we should reconsider making deprecation warnings only > visible by explicitly enabling them and instead make them visible > by default. > > This would create more noise for users, but for the better, since > planned changes then become more visible and can be addressed > either by silencing the warning (and opening a ticket to get > the change addressed) or by fixing the code in a new release. We've tried this in the past, and the problem is that it hits the wrong people. Users typically can't do anything directly about the warnings, other than report them to the offending packages. So the person hit by the warning then has an indefinite wait while the upstream package fixes the issue (either fully, or just by temporarily suppressing the warning) and releases a new version (which depending on the project release cycles and processes, may not be a straightforward replacement for the previous version). > If package authors were to get into the habit of doing the > silencing for their users after opening a ticket, that would > probably make the whole process more streamlined and effective. If that was what actually happened, then maybe this would work. But unfortunately this is open source, and many projects haven't got the resources to make emergency releases to silence a warning for their users. Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/XYLETQTARRX32IYQXPKSGNLC57OMCE22/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: PEP 563 and Python 3.10.
On Wed, 21 Apr 2021 at 12:24, M.-A. Lemburg wrote: > > Isn't that an educational problem ? Adjusting reporting of > warnings isn't all that hard: > > https://docs.python.org/3/library/warnings.html#the-warnings-filter > > Perhaps it's just a usability issue. We could have venvs help > us a bit with this by e.g. making such settings "global" per > venv, without the user having to configure PYTHONWARNINGS > or writing a sitecustomize.py for this purpose. Maybe. In my own personal experience, I hit this sort of thing when using tools. Consider for example black - if that triggered a warning, I'd report it, but then what would I do? Edit my copy of black (possibly in multiple environments) to suppress the warning? Block the warning globally which means I then don't see it for other projects and hence don't report it to them? Work out the precise incantation to suppress it just for black? In practice, I just moan a lot about the warning, and vote to suppress warnings by default next time the question comes up :-) So yes, maybe it's an education/usability issue, but if so it's one that's hard to fix. If we can work out a way for users (who may well have limited programming knowledge) to just "push a button" to say "I reported that issue to black, now stop bothering me about it for this version of black (at least on this PC)" then that would be great. But at the moment I don't believe it's that simple. Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/2SJAQFXJOGQ7MIMT3XC5SUKKJLZKLSMH/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: core-dev chat
On Fri, 14 May 2021 at 19:51, Senthil Kumaran wrote: > > On Fri, May 14, 2021 at 11:07:12AM -0700, Brett Cannon wrote: > > > You could launch a poll on discuss.python.org and see if there's a clear > > winner. > > Yes, after hearing some opinions, I plan to do that. Right now, I guess > the choices I am thinking are > > - No, I am not interested in Chat. > - Focus on #python-dev IRC > - Focus on Zulip. Keep #python-dev for alerts. > - Gitter > - Discord > - Slack > > Platform + Community (number of votes) might help us come to a > consensus. The problem with this, I think, is that my choice would be * Whichever one people actually used In other words, this isn't a technology problem, it's a people problem. Do enough of the core devs actually *want* to hang out in a chat forum to achieve critical mass and make it worthwhile? Also, what would we talk about? Would it only be for things like "hey, does anybody know how X works, because I'm looking at bpo-" or would "social" conversations be acceptable? How far would that go? Funny cat videos? I'm half joking, but the truth is that a community is more than just technical questions, but I don't know how many of us would like that sort of community. But conversely, a platform that people simply "pop in to" when they have a question won't last very long. Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/M7EY5O7LKJR5TUQ2F5Z4G66GVB22QDSQ/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: core-dev chat
On Fri, 14 May 2021 at 21:18, Senthil Kumaran wrote: > > On Fri, May 14, 2021 at 08:53:13PM +0100, Paul Moore wrote: > > The problem with this, I think, is that my choice would be > > > > * Whichever one people actually used > > That's self-referencing, and unsolvable. It is, but it's true nevertheless. I suppose I'd have to abstain in that case. Would an "I'd be happy to have a chat platform but don't care which one" option defeat the purpose? > > In other words, this isn't a technology problem, it's a people > > problem. > > Both. I didn't suggest this is technology problem. We, have to > choose one as per majority convenience. Fair enough. That suggests that abstaining is the right answer for people without a preference, I guess. > > Do enough of the core devs actually *want* to hang out in a > > chat forum to achieve critical mass and make it worthwhile? > > Yes, that's why the choice exist that "We don't want any chat platform". OK, as long as you don't also assume that abstention means "not interested in chat". > > Also, what would we talk about? > > Just as #python-dev or #python, but more constrained to committer > discussions. Sorry, I don't use IRC so that doesn't help much (maybe that suggests I should have said my preference is "anything except IRC" :-)) Although the reason I never really did much with IRC was that it seemed a bit too focused on the drop-in "hey, can anyone help" type of interaction. So if that's a fair assessment then I can go with that (and in that case I'd revise my vote to "not interested", as I probably wouldn't stay logged onto a chat system if it was limited to that type of conversation). Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/KMN3UZ2EUW4QICU2REEQT3QMW5PHCK74/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: core-dev chat
On Sat, 15 May 2021 at 03:14, Dong-hee Na wrote: > > Believe it or not, there are people who are not familiar with the IRC culture. > And those people are who enter the opensource culture after the 2010s. > That period coincides with the growth of GitHub. > > So I'm also a supporter of new communication tools. > Here the list below is my consideration. [...] Those are all good points. I'll add one more: * Does it have a good web-client experience? Not everyone wants to run an additional client, so being able to get the full client experience in a browser tab is important. In case it's not clear, I'd *like* a chat-style community, but I'd prefer it to be a little more "social". We have plenty of "work-related" communication channels, but IMO we don't really have anywhere that's the online equivalent of the workplace "hanging out around the coffee machine" interactions (which are often very productive work-related conversations, but can also be purely social). Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/452YY7GKRWVZGQE7IJULFHBQNSJFFTQX/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: core-dev chat
On Sat, 15 May 2021 at 16:58, Senthil Kumaran wrote: > > I see lots of vague complaining and no concrete argument. > > Really? I don't see that way. So far, I see that few others find > settling upon chat solution will be useful for core-dev too. I see a general interest in *having* some sort of community chat, but no real plan on how to get a critical mass of people on a chat system. Specifically, we tried Zulip and it failed, in the sense that basically no-one uses it. So let's start by working out *why* it failed. I don't see any point in having a vote, which comes up with the conclusion that (say) people like Discord, if we then set that up and there's no-one on there. If we were to ask the question, why did people stop logging into Zulip as part of their daily sign-in routine (or why did they never even start doing that), what would the answers be? Mine would be simply "because no-one was there". More specifically, even if people were there, there were no conversations going on. Yes, it's a circular argument, unless people use a system no-one will use it. I get that. But how do we break that cycle? Explicitly making it more of a social community (while still allowing that we're all technical so casual technical questions still count as social ;-)) might make a difference. As might a deliberate effort to keep people engaged. But just choosing a new tool and hoping people like it enough for the community to "just happen" seems destined to fail. Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/5FI5XY4F2AAJEO4IX6WQ2XBUVDA6LQ3Z/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: core-dev chat
On Mon, 17 May 2021 at 11:32, Thomas Wouters wrote: > There's also the social dimension that is simply not present in email -- for > good reason. There are many messages I have not sent simply because it's > email, so it's more effort and carries much more weight. Agreed. An example of something I'd consider "semi-social" would be "hey - does anyone know a good library for doing XXX" or "SQLAlchemy baffles me, does anyone use it or know a good tutorial?" These aren't core dev questions - they don't relate to anything I'm doing on CPython, but they are the sort of questions I'd ask a bunch of friends who I know use Python and are experienced/good coders. They also tend to be relatively immediate - it's no big deal if no-one can help, but conversely if I get an answer 3 days from now I'll probably already have worked around the issue - and tend to be conversation triggers (chat about how hard it is to discover new interesting libraries, or about how writing tutorials is an art form that a lot of projects could do with help on). > Discourse is better at this with 'likes' as well as direct linking and > cross-referencing. It's still not the same as Discord or similar chat > programs. I think in general modern apps do better on the "social" aspect. Email is still my preferred option for extended discussions, longer or more complex topics, etc, but not so much for things that are more "in the moment". Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/434M5TZYCO43VQ5BASXDJUESQLUADTF5/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: core-dev chat
On Tue, 18 May 2021 at 15:14, Antoine Pitrou wrote: > > > Le 18/05/2021 à 15:36, Senthil Kumaran a écrit : > > Antoine Pitrou wrote: > >>> I'll ask the question again: what are the « evolving needs » that are > >> not addressed by Zulip, but would be addressed by *another* chat system? > > > > I don't understand this question, and lost the context too if it was > > addressed to me. > > > > The fact is, Zulip simply isn't used by python-dev. > > It didn't fly, and could be due to multiple reasons, not just social ones. > > Sure. So why don't you just *ask* people why they don't use Zulip, > instead of trying to invent explanations? > > Personnally, I can already answer: I don't use the python-dev Zulip > because I'm not looking for a place where to hang out persistently for > python-dev topics. Perhaps I might take a look from to time, but that's > all. And for me, I dropped Zulip because there was never anything of interest to me happening on there. Paul ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/ZHMTEJJ5HMQ54Y5BAY6ZHZMWC6YFECHB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Please make sure you're following good security practices with your GitHub account
On Wed, 16 Jun 2021 at 06:15, Julien Palard via python-committers wrote: > > I do use a Yubikey too. I'm not particularly bothered by the debate over 2FA (I have a 2FA app on my phone that I use and that's sufficient) but I'd like to offer a counter argument to everyone saying Yubikeys are a straightforward solution (not particularly picking on you, Julien, a few people have suggested this option). Maybe they are for a lot of people, but I have 3 PCs, a tablet and a phone that I routinely use for github access. At least one is critically short of USB ports from all of the other junk I have plugged in. I checked the Yubikey website and their recommendation (based on my answers to their questions about how I would use them) was to buy *three* keys, each of which was priced at about €40-50. That's a lot of money¹. And there was some comment about not working completely seamlessly with my iPad, which worried me, as well. And even with 3 keys, that's still going to mean swapping keys as I have more than 3 devices... So while I support the idea of having 2FA (I spotted a suspicious attempt to log into my account that failed, like Brett, so there's definitely a need) I don't think we should assume any particular solution will work universally - and finding a working solution might be hard for some people (for a long time, I didn't use a smartphone regularly, and none of the available 2FA solutions really worked for me). It sounds like a Yubikey might be a reasonable solution for Tim, but only he can say that for sure, and we should avoid letting our enthusiasm for our own preferred solution blind us to the fact that it might not suit everyone. (Sorry - some battle scars showing there, I've had rather too many people tell me to get a Yubikey when it really doesn't work for me. It soured me on 2FA for quite some time, until I found a solution that suited me...) Paul ¹ Yes, I know it's way less than I spent on all those PCs!!! ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/6GFHYEEO6G6OQQ26K6FW4FO4R34PEA2L/ Code of Conduct: https://www.python.org/psf/codeofconduct/
