[python-committers] Re: [RELEASE] Python 3.11 release candidate 1 (3.11.0rc1) is available

On 8/8/2022 12:59 PM, Pablo Galindo Salgado wrote: Python 3.11.0 is almost ready. This release, 3.11.0rc1, is the penultimate release preview. You can get it here: ## This is the first release candidate of Python 3.11 https://www.python.org/downloads/release/python-3110rc1/

[python-committers] Re: What's the schedule for the core sprint?

I have the same question as Eric: How do I get to the sprint channels. ___ 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-com

[python-committers] Re: Dates for the core dev sprints

On 10/11/2021 2:02 PM, Ewa Jodlowska wrote: core devs only; also don't forget to record your Discord username, which is formatted as r".+#\d+", to https://github.com/python/voters/  if you have not already) Is voters/python-core.toml the one and only file to

[python-committers] Delete bpo spammer user

One of the bpo admins should delete bpo user skoolbeep/Spammer 'Spammer' is the 'real name'! https://bugs.python.org/user?username=skoolbeep&realname=&github=&%40action=search see https://bugs.python.org/issue44550 ___ python-committers mailing list --

[python-committers] Re: Roundup to GitHub Issues migration

On 6/23/2021 4:28 PM, Inada Naoki wrote: FWIW, GitHub announced new powerful Issues today. https://github.com/features/issues It may fill some gap between GitHub Issues and Roundup. I signed up for the beta waiting list so I could experiment with it. Someone else would have to sign up 'Python

[python-committers] Re: Please make sure you're following good security practices with your GitHub account

On 6/14/2021 3:38 PM, Brett Cannon wrote: I have discovered someone tried to break into my GitHub account (you can check yourself by going to https://github.com/settings/security-log and looking for "failed to login" attempts for potentially odd geogra

[python-committers] Re: Please make sure you're following good security practices with your GitHub account

On 6/14/2021 5:06 PM, Donald Stufft wrote: On Amazon, Yubikey is $45-55 for 3 kinds of interfaces. One must buy the right one. And then configure with each remote account. Picture show usb-c keys plugged into laptops. but desktops and monitors with usb have standard usb-2/3 ports. Fido NFC

[python-committers] Re: core-dev chat

On 5/15/2021 1:01 PM, Paul Moore wrote: 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 never tried it because it was introduced about the same time as 'discuss', and it was enough for me to learn *that*

[python-committers] Re: Important: Python3.10 what's new

On 5/10/2021 2:42 PM, Pablo Galindo Salgado wrote: Hi everyone, Now that we are in the beta period for 3.10 is very important that we make sure that all improvements, new APIs and deprecations are reflected in the 3.10 what's New document. Remember that What's New in Python 3.10 should be *i

[python-committers] Re: [Release manager team communication] master blocked until 3.10 beta 1 is released

On 5/3/2021 5:09 PM, Victor Stinner wrote: Hi, Please don't attempt to merge PRs until the GitHub issue described below is solved ;-) Pablo renamed the default "master" branch to "main" (in a live Twitch stream ;-)) but got a GitHub internal error! Maybe it's because the dialog announced that 1

[python-committers] Irrelevant .whl attachment to tracker issue

https://bugs.python.org/issue41608 Userid ttx11529 uploaded, without posting anything, a file called pb_tool-3.1.0-py3-none-any.whl. As best I understand, if the name is not forged, this is a file that pip would use to install pb_tool 3.1.0 to any 3.x python. https://pypi.org/project/pb-tool/

[python-committers] Re: [Release management team communication] 3.8.10, the last regular bugfix release for the 3.8 series, is 1 week away

On 4/26/2021 4:18 PM, Łukasz Langa wrote: change. While there's still 2200 open issues on BPO listing 3.8 as one of the affected versions, I hope we won't be seeing that many PRs this week ;-) Perhaps 200 of those are IDLE issues and I don't expect to commit any to 3.8 (unless I get to a do

[python-committers] Re: PEP 563 and Python 3.10.

On 4/20/2021 2:57 PM, Thomas Wouters wrote: We need to roll back the change that made stringified annotations the default, at least for 3.10. (Pablo is already working on this.) I also agree and thank Pablo in advance. .  - PEP 563 provides no warning to users of the feature it’s disabling

[python-committers] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

On 2/8/2021 3:07 PM, Python Steering Council wrote: After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. Thank you for your collective time and effo

[python-committers] Fwd: [Python-checkins] Adding "stale" GitHub Action (GH-21247)

As a result of this merge, I have so far received 3 emails with this scary message. "This PR is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 5 days". https://github.com/python/cpython/pull/23100#issuecomment-745680212 http

[python-committers] dependabot gone bonkers?

This morning I woke to find that dependabot had added two new branches to my cpython fork https://github.com/terryjreedy/cpython/branches and had created corresponding PRs https://github.com/terryjreedy/cpython/pull/3 https://github.com/terryjreedy/cpython/pull/4 Whether all forks or all committ

[python-committers] Re: Is adding an email package "defect" a new feature?

On 10/26/2020 3:09 PM, Brett Cannon wrote: Our lesson from our "innocuous" addition of booleans makes me leery of anything that tweaks the API such that it isn't compatible in the same feature release. There were other instances, such as a undocumented io change related to stream position (I

[python-committers] Re: cherry_picker problem

On 9/13/2020 7:58 PM, Eric V. Smith wrote: On 9/13/2020 7:42 PM, Terry Reedy wrote: On 9/13/2020 5:32 PM, Eric V. Smith wrote: For reasons I don't understand, https://github.com/python/cpython/pull/9 failed to backport to 3.9. The message says: Sorry @eamanu <https://github.co

[python-committers] Re: cherry_picker problem

On 9/13/2020 5:32 PM, Eric V. Smith wrote: For reasons I don't understand, https://github.com/python/cpython/pull/9 failed to backport to 3.9. The message says: Sorry @eamanu , I had trouble checking out the |3.9| backport branch. Please backport using cherry_pi

[python-committers] Re: Planning a hotfix Python 3.8.5

On 7/16/2020 1:36 PM, Łukasz Langa wrote: there are 3 security-related fixes in the 3.8 branch post 3.8.4, one with a CVE, another with a pending CVE if I understood Steve correctly. I'd like to release a hotfix 3.8.5 on Monday. Since this is a special security-focused release, it will be ess

[python-committers] Re: GitHub pull requests

On 7/9/2020 3:29 PM, Mariatta wrote: If you want the associated bpo ticket to be closed when the PR is merged, you have to add the commit message saying "closes " (Note that we should document this: https://github.com/python/devguide/issues/502) If there are backports, which is nearly always

[python-committers] Re: GitHub pull requests

On 7/9/2020 3:24 PM, Mariatta wrote: is it closed automatically ? What is "it"? The PR itself? yes the PR becomes closed if it is merged. The branch in your github fork is not automatically deleted. There is a button on the PR to do so. I don't know if the devguide mentions this. The

[python-committers] Re: The Night’s Watch is Fixing the CIs in the Darkness for You

On 4/3/2020 2:32 PM, Victor Stinner wrote: Hi, tl; dr Maybe the 1090 pending pull requests will have to be rebased on master to be able to be merged, unless we enhance our CI to always test PRs after rebasing them on the master branch. I hope you mean doing an update merge rather than a rebase

[python-committers] Re: Currently working on the release of Python 3.8.0rc1

On 9/30/2019 3:48 AM, Łukasz Langa wrote: To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who i

[python-committers] Re: Bedevere will now re-request reviews when PR authors state they are ready for another review

On 9/10/2019 10:09 AM, Brett Cannon wrote: And because I just educated at least 3 people here at the Bloomberg sprints about how to easily find their PRs that they have in their review queue, there are links in the top black bar of GitHub for looking at issues and pull requests relevant to you

[python-committers] Re: Make AppVeyor CI non-mandatory during the CPython sprint?

On 9/9/2019 12:46 PM, Benjamin Peterson wrote: On Mon, Sep 9, 2019, at 16:50, Victor Stinner wrote: Hi, I see a high activity on pull requests on the CPython project, likely because of the CPython sprint. Sadly, the AppVeyor is still slow and still has only 2 jobs in parallel. A couple of y

[python-committers] Fwd: Python-checkins post from webhook-mai...@python.org requires approval

Some years ago I was added to python-checkins as a moderator, but not a full list owner, to occasionally discard the very occasional spam. I don't know who the real list owner is, if anyone. Recently, checkins from Łukasz Langa are being held. I have no idea why, or what implicit destination

Re: [python-committers] Python 3.8.0b1 not there yet

> On 4 Jun 2019, at 21:43, Terry Reedy wrote: >> May I merge non-intrusive changes (to IDLE)?On 6/4/2019 3:46 PM, Łukasz Langa wrote: You can but they won't be in beta1 anymore. I am waiting for .exe files to branch 3.8 out. Sources and Mac binaries for beta 1 are already built.

Re: [python-committers] Python 3.8.0b1 not there yet

On 6/4/2019 12:12 PM, Victor Stinner wrote: Le mar. 4 juin 2019 à 16:45, Mark Shannon a écrit : Does this mean that https://github.com/python/cpython/pull/6641 isn't going to get in 3.8? Maybe we can consider to put it in beta2, but please don't push any further intrusive change before beta1!

Re: [python-committers] Promote Mark Sapiro and Abhilash Raj as core developers

On 5/13/2019 7:11 PM, Barry Warsaw wrote: On May 13, 2019, at 01:14, Victor Stinner wrote: I'm no longer sure myself that I can define them. I prefer to repeat what others say :-) Basically, a core developers is someone who produces commits :-) That's one definition. But, IMHO not a correct

Re: [python-committers] [Python-Dev] Farewell, Python 3.4

On 5/8/2019 11:46 AM, M.-A. Lemburg wrote: Thank you for having been 3.4 release manager, Larry ! I especially appreciate being able to have proper signatures for builtin functions. ___ python-committers mailing list python-committers@python.org ht

Re: [python-committers] [RELEASE] Python 3.8.0a3 is now available for testing

On 3/26/2019 5:11 AM, Łukasz Langa wrote: It's time for the third alpha of Python 3.8.0. Go get it here: https://www.python.org/downloads/release/python-380a3/ This page https://www.python.org/download/pre-releases/ still lists and links to .0a2 ___

Re: [python-committers] Promote Stefan Behnel as a core developer

ectly) Terry Reedy schrieb am 24.03.19 um 19:27: > On 3/24/2019 12:14 PM, Serhiy Storchaka wrote: >> I propose to promote Stefan Behnel (aka scoder on the tracker and >> GitHub) as a core developer. > > Have you asked Stefan if he would like the privilege, accept it, and >

Re: [python-committers] Promote Stefan Behnel as a core developer

On 3/24/2019 12:14 PM, Serhiy Storchaka wrote: I propose to promote Stefan Behnel (aka scoder on the tracker and GitHub) as a core developer. Have you asked Stefan if he would like the privilege, accept it, and would at least occasionally use it? Perhaps not one from us is surprised that he

Re: [python-committers] Vote to promote Stéphane Wirtel as a core dev

On 3/22/2019 4:56 PM, Victor Stinner wrote: Le ven. 22 mars 2019 à 19:45, Brett Cannon a écrit : We discussed this and we think an anonymous vote on discuss.python.org is probably best for this sort of thing. I agree. Auto vote counting, with possibility of changing one's vote from discuss

Re: [python-committers] Vote to promote Stéphane Wirtel as a core dev

On 3/22/2019 11:34 AM, Victor Stinner wrote: Julien Palard and me (Victor) propose to promote Stéphane Wirtel as core developer. +1 Thank you for the nice review of his work, so I know him better. He got 57 commits merged into the master branch of Python: authored 46 commits + co-authored 1

Re: [python-committers] Last-minute request: please backport bpo-33329 fix to 3.4 and 3.5

On 3/2/2019 9:55 AM, Antoine Pitrou wrote: Le 02/03/2019 à 07:05, Larry Hastings a écrit : This bug in bpo-33329: https://bugs.python.org/issue33329 was fixed for 3.6+, but it also affects 3.4 and 3.5.  The bug is that with newer versions of glibc--which I'm pretty sure has shipped on a

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

On 2/11/2019 12:48 PM, Victor Stinner wrote: Hi, tl; dr How can we decide if we should stop using mailing list or if we should stop using discuss.python.org? If 'mailing list' == 'all lists', neither. It should be a list-by-list decision. If 'mailing list == 'python-committers', neither, a

[python-committers] Voting thank you

I just read the PEPs and voted (with a few hours to spare). I want to thank the people who organized the voting, wrote the summary of other projects, wrote the PEPs, and who helped the PEP authors improve the proposals. I like the ranking system. Even if my (mild) first choice (tonight) doe

Re: [python-committers] GOVERNANCE VOTE SCHEDULE UPDATE: Dec 1 - Dec 16 2018

On 11/15/2018 6:47 PM, Łukasz Langa wrote: Thank you to everybody who voiced concern that the originally planned voting schedule of Nov 16 - Nov 30 was rushed. In the interest of ensuring everybody feels included, as well as to allow time for PEP 801x review and clarifications, Barry Warsaw an

Re: [python-committers] discuss.python.org participation

On 10/11/2018 4:30 AM, Antoine Pitrou wrote: What concerns me is that there are several long-time and/or prominent developers who are not even registered (*) on discuss.python.org. For example Benjamin Peterson, Larry Hastings, Raymond Hettinger, Stefan Krah, Terry Reedy. This provoked me to

Re: [python-committers] python-committers is dead, long live discuss.python.org

On 9/29/2018 4:51 AM, Serhiy Storchaka wrote: 29.09.18 03:45, Łukasz Langa пише: >> (To paraphrase) 'We' are switching committers-list to Discourse. Who is this 'we'? I don't remember any discussion, let alone a vote. On 28 Sep 2018, at 23:04, Serhiy Storchaka wrote: Do you use NNTP? Like

Re: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

On 9/21/2018 6:55 AM, Christian Heimes wrote: I don't understand why you are drawing the reverse conclusion here. Can you give me one concrete example, in which a French, German, or any other non-US American taboo was violated and not counteracted with swift reaction? Are you talking about som

Re: [python-committers] How to retry backport?

On 8/12/2018 9:22 AM, Eric V. Smith wrote: https://github.com/python/cpython/pull/8745 This failed (I think travis, but can't tell now). When Travis fails, it is often just one of its two required subtests. At the far right of the summary page, at the end of each test line, is a little, not

Re: [python-committers] Reminder of BDFL succession timeline + CFP

On 8/2/2018 8:01 PM, Yury Selivanov wrote: On Thu, Aug 2, 2018 at 4:43 PM Brett Cannon wrote: On Wed, 1 Aug 2018 at 17:58 Yury Selivanov wrote: On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya wrote: [..] I'm open to extend the dates, and even wait another year if we need to. Or do folks wa

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

On 7/19/2018 1:10 PM, Mariatta Wijaya wrote: On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon > wrote: I had Carol's same worry that while it's great to have a "no sooner than" date, we also can't let this drag on and we have no "settle by" date, else we risk

Re: [python-committers] If I backport to 3.7, it will not go into 3.7.0, correct?

On 6/23/2018 8:37 AM, Eric V. Smith wrote: I have a few things I want to fix in 3.7.1, but don't need to be 3.7.0. I can backport those to the 3.7 branch now, correct? Correct. 'backport 3.7' == backport into 3.7.1. I have done this several times already. Reading Ned's message I wasn't exac

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

On 6/18/2018 2:37 PM, Brett Cannon wrote: On Mon, 18 Jun 2018 at 11:17 Antoine Pitrou <mailto:anto...@python.org>> wrote: Le 14/06/2018 à 04:30, Terry Reedy a écrit : > On 6/13/2018 7:03 PM, Carol Willing wrote: >> +1 With Victor's mentoring (1 or 2 mon

Re: [python-committers] Changing commiter status

On 6/18/2018 3:24 PM, Jack Jansen wrote: I know that this is the case for me. I wouldn’t _dream_ of committing anything (after 10 years or so) without first consulting with current core developers, etc. We would, of course, help you get back up to speed with the current workflow, if you wish

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

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

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

On 6/13/2018 12:16 PM, Victor Stinner wrote: Hi, I propose to promote Pablo Salingo Salgado as a core developer and so open a vote during one week. If there is no strong opposition, I will promote him but also continue to mentor him for a least one month. Pablo is contributing frequently to Pyt

[python-committers] Wrongly stopping merges discourages merging.

When we used hg, core dev committers could actually commit to the repository when they judged it appropriate. When we moved to github, Brett, with whoever's approval, decided that we should no longer be trusted to make commits without approval of a couple of mindless robots. However, the prem

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

On 6/1/2018 7:07 PM, Mariatta Wijaya wrote: Yup, the "mystery" was just for fun 😛 There is no secret. I've been thinking that we should start using GitHub issues instead of the b.p.o. I realized not everyone was able to get to the language summit, and I fully intended to update python-committ

Re: [python-committers] Quick reminder: please don't push long-lived dev branches to the CPython repo

On 5/25/2018 1:43 PM, Brett Cannon wrote: If you create a dev branch that is going to live for less than 24 hours because you edited some typo in the docs or something through GitHub's UI, then that's fine. But long-lived dev branches should be done in one's personal fork. This is for two reaso

Re: [python-committers] Bring back Travis & AppVeyor, make VSTS non-blocking

On 5/18/2018 12:25 AM, Gregory P. Smith wrote: VSTS is clearly not yet a stable continuous integration platform.  It needs to be made non-blocking, and AppVeyor and Travis need to be brought back! Examples: https://github.com/python/cpython/pull/6938#issuecomment-389908094    Windows broke -

Re: [python-committers] Can I just rerun a test on AppVeyor?

On 5/17/2018 10:36 PM, Zachary Ware wrote: On Thu, May 17, 2018 at 8:09 PM, Terry Reedy wrote: I can restart a test on just Travis when AppVeyor (and now MSTS) all passed. But for the last few hours, test_async has failed 1/4 to 1/3 of the runs. This means that test_async failed twice, so I

[python-committers] Can I just rerun a test on AppVeyor?

I can restart a test on just Travis when AppVeyor (and now MSTS) all passed. But for the last few hours, test_async has failed 1/4 to 1/3 of the runs. This means that test_async failed twice, so I suspect that it actually fails about half the time. A connection error seems to be the main cul

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

Can VSTS run GUI tests on any of the systems? Right now, only Appveyor and one or two of the Windows buildbots do so. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Con

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

On 5/17/2018 10:07 AM, Steve Dower wrote: Feel free to email me with any questions or feedback, either on or off-list. When a test fails and verbose test by test output is displayed, it would be really nice if error lines, or at least 'ERROR' were highlighted more somehow. Either in red (ha

Re: [python-committers] AppVeyor and Travis-CI

On 5/15/2018 12:20 PM, Alex Gaynor wrote: FWIW, attached is an image pointing out the re-run button. If you're not seeing those it means either a) you're not logged into Travis, b) somehow it's not picking up your permissions correctly. Is there anything in the devguide about this? The first

Re: [python-committers] AppVeyor and Travis-CI

happened again on my next 3.6 only patch. I restarted just Travis and it passed. The failure rate the last 24 hours has been about 1/3. 2018-05-15 16:36 GMT-04:00 Terry Reedy : I am getting repeated bogus failures, completely unrelated to a trivial patch, more often than not, on Travis-C

Re: [python-committers] AppVeyor and Travis-CI

I am getting repeated bogus failures, completely unrelated to a trivial patch, more often than not, on Travis-CI For instance, https://travis-ci.org/python/cpython/jobs/379349709 2 tests failed: test_asyncio test_multiprocessing_forkserver 1 test altered the execution environment: test_im

Re: [python-committers] AppVeyor and Travis-CI

On 5/14/2018 9:49 PM, Eric V. Smith wrote: I accidentally checked in some test files, and they got backported to 3.7. I pushed a commit to delete them, and it was committed to master. But in the 3.7 backport, something has gone wrong with AppVeyor and Travis-CI. https://github.com/python/cpy

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

On 5/2/2018 5:49 AM, Victor Stinner wrote: You asked two different questions, hence two answers. 1. The title asks "Do I like the PEP 572 Assignment Expressions"? Yes, at least +.5, and if forced, I might well round up to 1. The poll is on the *current* PEP. I propose 4 choices: 2. However,

Re: [python-committers] Orphaned backports

On 4/22/2018 12:16 PM, Serhiy Storchaka wrote: miss-islington is an awesome bot! It makes fixing bugs in multiple versions much simpler. You need just accept automatically created backporting PRs. But there is a downside. miss-islington makes the life so easier, that sometimes you forgot abou

Re: [python-committers] Issues with hundreds of commits being opened and closed -- what's going on?

On 2/15/2018 7:42 PM, Mariatta Wijaya wrote: I've also created https://github.com/python/bedevere/issues/69 so that the review requests from such PRs can be dismissed automatically. This is a great improvement over the PR being left open until someone manually closes it. Not sure if there's

Re: [python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

On 2/5/2018 9:34 AM, Nick Coghlan wrote: On 6 February 2018 at 00:07, Mariatta Wijaya wrote: Some notes and implicationss: - The expectation is that the commit message has already been cleaned up on the master branch and that Miss Islington has correctly copied the title and commit message.

Re: [python-committers] cherry picking, miss islington, and generated files

On 2/3/2018 9:54 AM, Barry Warsaw wrote: On Feb 2, 2018, at 20:40, Mariatta Wijaya wrote: Sure, I sort of asked this in the past: what are the generated files, how to identify them, is there a pattern? I’m not sure there’s going to be a pattern so much as a list of such files. There are a

Re: [python-committers] I created the "needs backport to 3.7" label on GitHub

On 1/31/2018 7:03 PM, Barry Warsaw wrote: $ git worktree add ../3.7 3.7 # ftw! f:\dev\3x> git worktree add ../37 3.7 fatal: invalid reference: 3.7 f:\dev\3x> git worktree add -b 3.7 ../37 3.7 fatal: Not a valid object name: '3.7'. # However f:\dev\3x> git checkout 3.7 # 'exposes' the existi

Re: [python-committers] [IMPORTANT] post 3.7.0b1 development now open

On 1/31/2018 8:04 PM, Ned Deily wrote: In the cpython repo, there is now a 3.7 branch. Starting now, all PRs destined for 3.7.0 should get cherry-picked from master to the 3.7 branch or just pushed to 3.7 if only applicable there. New features should continue to be pushed to the master branch fo

Re: [python-committers] trivial tag on GitHub?

On 1/26/2018 1:28 AM, Ethan Furman wrote: I created a new pull request to add a forgotten news entry, and now it's going through all the pre-checks, etc. I seem to recall we could add a "trivial" tag to an issue to skip those.  Is that still true, and if so, how? 'trivial' was replaced by 's

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

On 1/25/2018 4:31 PM, Victor Stinner wrote: Hi, The best would be able to have a bot merging a pull request once tests pass and a core developer asked a merge. I'm not talking about the current approval using review, but something new, like adding a special comment like "Merge". Such comment wou

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

On 1/25/2018 1:52 PM, Brett Cannon wrote: On Wed, 24 Jan 2018 at 10:12 Victor Stinner > wrote: AppVeyor usually takes between 30 min and 1 hour to check a PR, Yesterday, AppVeyor surprised me by finishing in about 6 minutes, handily beating Travis. I

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

On 1/24/2018 6:29 PM, Eric V. Smith wrote: On 1/24/2018 6:23 PM, 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

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

On 12/8/2017 11:20 AM, Victor Stinner wrote: 2017-12-08 14:19 GMT+01:00 Ezio Melotti : In my opinion, the role of the mentor should boil down to: 1) be a reference for the new core dev and be available in case everything else fails (e.g. if no one else answers a question); 2) be responsible for

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

On 12/6/2017 1:45 PM, Ned Deily wrote: On Dec 6, 2017, at 12:45, Ezio Melotti wrote: Depends on what you exactly mean with "award". Contributors might want to be able to edit more fields on the tracker, and the triage bit allows them to do it. This is beneficial for both the contributor and th

Re: [python-committers] Adding Ivan Levkivskyi as a core committer

On 12/5/2017 8:00 PM, Guido van Rossum wrote: I'd like to propose Ivan Levkivskyi as a new core committer. He's (re-)written most of the typing.py module and will do so again for Python 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562), is co-author on several more (483,

Re: [python-committers] OK to back-fill "awaiting" labels on open issues?

On 10/6/2017 5:29 PM, Brett Cannon wrote: I noticed today that out of about 19 pages of issues, only the first 5 have "awaiting" labels. Would people object if I back-filled those open issues lacking an "awaiting" label? For those that have a "changes requested" review a comment that said rough

Re: [python-committers] Requesting reviews

On 10/6/2017 8: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) bu

[python-committers] Merging when assignee does not respond.

https://bugs.python.org/issue30085 https://github.com/python/cpython/pull/1171 were submitted last April. Raymond assigned PR to himself, reviewed it in May. Contributor Sanket revised according to reviews, in my opinion adequately. Repeated pings on both issue and PR have not been answered.

Re: [python-committers] Reminder: snapshots and releases coming up in the next several days

On 9/13/2017 12:35 PM, Ned Deily wrote: 2017-09-18 1200 UTC cutoff: - Python 3.6.3 rc1 Also on 2017-09-18: - Python 3.7.0 alpha 1 Have you branched these off so that further merges go into 3.6.4 and alpha2? ___ python-committers mailing list pyt

Re: [python-committers] AppVeyor failure on test_asyncgen?

On 8/16/2017 2:32 PM, Antoine Pitrou wrote: One of my PR builds got an AppVeyor failure in test_asyncgen and I really doubt it is due to the PR itself: https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.5366#L682 The first failure message: test_async_gen_asyncio_gc_aclose_09 (test.

Re: [python-committers] mention-bot is dead, long live the (misnamed) CODEOWNERS file!

Rearranging things in order. I asked > Do people on a team have to be core-developers? The broader question is whether active people who want notifications have to be a committer to get automatic notifications of a PR and in particular a review request. It appears that anyone with a github

Re: [python-committers] mention-bot is dead, long live the (misnamed) CODEOWNERS file!

On 8/2/2017 10:37 AM, Nick Coghlan wrote: On 2 August 2017 at 07:09, Christian Heimes wrote: I suggested teams to make the file a bit easier to maintain. The rule format works differently than the old mentionbot format. In the old format we had a relationship user -> files. The new CODEOWNERS f

Re: [python-committers] New workflow - some questions

On 7/29/2017 4:40 AM, Paul Moore wrote: 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. As I understand

Re: [python-committers] AppVeyor was unable to build non-mergeable pull request

On 7/25/2017 10:22 PM, Brett Cannon wrote: So are you requesting we stop building on AppVeyor? Since it runs gui tests, and Travis does not, it is very useful. For the last week, it has mostly always run. On Tue, Jul 25, 2017, 17:31 Victor Stinner, > wrote:

Re: [python-committers] I just gave Gareth Rees traige privileges on the tracker

On 7/20/2017 12:10 PM, R. David Murray wrote: I haven't actually heard back from him yet since I just emailed him, but I've never had anyone turn down triage privs :) The trigger was that I closed two issues this week that he comment on that it would have been nice if he had been able to just cl

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

On 7/18/2017 2:31 PM, Brett Cannon wrote: Once again, glad the goals are panning out. :) Key thing has always been to increase our bandwidth and part of that was always to push more on to contributors so they can be more self-servicing. * most contributors create backports (using cherry-

Re: [python-committers] Please edit the commit message when merge a PR

On 7/10/2017 10:49 AM, Berker Peksağ wrote: On Mon, Jul 10, 2017 at 4:14 PM, Serhiy Storchaka wrote: When a PR is consistent on several commits, the final commit message composed by GitHub contains messages of all these commits: "fix typo", "address yyy comments", "revert zzz". If the initial c

Re: [python-committers] Revert changes which break too many buildbots

On 7/5/2017 10:03 AM, Victor Stinner wrote: 2017-07-05 15:51 GMT+02:00 Victor Stinner : Ok, since I spent weeks on fixing buildbots, I'm now more confident that our buildbots are super stable. Since a test_datetime change introduced a *regression* (ARMv7 started to fail), I reverted the first co

Re: [python-committers] New workflow change: Welcome to blurb

On 6/24/2017 12:45 PM, Larry Hastings wrote: On 06/24/2017 09:40 AM, Terry Reedy wrote: On 6/23/2017 11:24 PM, Larry Hastings wrote: > You can install blurb from pip: > > % pip3.6 install blurb This does not seem to work right. On Windows: C:\Users\Terry>py -3 -m pip i

Re: [python-committers] New workflow change: Welcome to blurb

On 6/23/2017 11:24 PM, Larry Hastings wrote: > You can install blurb from pip: > > % pip3.6 install blurb This does not seem to work right. On Windows: C:\Users\Terry>py -3 -m pip install blurb Collecting blurb Downloading blurb-1.0-py3-none-any.whl Installing collected packages: blurb S

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

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

Re: [python-committers] Bedevere now automatically removes "needs backport to *" labels

On 6/20/2017 11:36 AM, Victor Stinner wrote: 2017-06-20 16:56 GMT+02:00 Mariatta Wijaya : I think it's because there was no 'needs backport to 3.4' label from PR 1849, so it doesn't make the comment about 3.4 backport PR. Oh, I see. These labels don't exist :-) Maybe we should add them, I wo

Re: [python-committers] Proposing Carol Willing to become a core developer

On 5/23/2017 2:15 PM, 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 c

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

On 5/3/2017 1:25 PM, Brett Cannon wrote: On Tue, 2 May 2017 at 11:29 Terry Reedy <mailto:tjre...@udel.edu>> wrote: It would easier to move discussion to bpo if there were a clickable link from PR to bpo, just as there is in the opposite direction. I believe that t

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

On 5/2/2017 2:36 PM, Christian Heimes wrote: On 2017-05-02 20:28, Terry Reedy wrote: On 5/2/2017 10:07 AM, R. David Murray wrote: On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" wrote: IMO, it's much easier for everyone to just always point people to BPO for discussio

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

On 5/2/2017 10:07 AM, R. David Murray wrote: On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" wrote: IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews. I agree with Mark-Andre here. It will take effort on our par

Re: [python-committers] Codecov and PR

On 4/27/2017 3:44 PM, Brett Cannon wrote: On Wed, 26 Apr 2017 at 22:36 Terry Reedy <mailto:tjre...@udel.edu>> wrote: On 4/26/2017 1:45 PM, Brett Cannon wrote: > E.g. I don't expect > test_importlib to be directly responsible for exercising all code in

Re: [python-committers] Codecov and PR

On 4/27/2017 1:52 AM, Ethan Furman wrote: On 04/26/2017 10:35 PM, Terry Reedy wrote: On 4/26/2017 1:45 PM, Brett Cannon wrote: :) But they are at least executed which is what we're really measuring here and I think all Ethan and I are advocating for. I thought Ethan was advocatin

  1   2   >