[python-committers] Need help with read-write checkouts (Win/TortoiseSVN)

Wanting to finish up the difflib issue (#2986) with my first commits, I read http://www.python.org/dev/faq/ (especially 2.2.2 and 2.3), loaded TortoiseSVN, and successfully did a read-only checkout. But when I try to do the needed read-write checkout, I get a blank plink screen and ... nothing.

[python-committers] Commit privileges for Eli Bendersky

Two years ago, Eli Bendersky submitted to the tracker one of several duplicate reports about problems with difflib.SequenceMatcher. After I consolidated and closed all issues but one, he wrote me, said he wanted to get more involved in Python development, and offered to help with that and

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

On 2/4/2011 1:41 PM, Jesus Cea wrote: Remember the rule: Patches in n+1 are a SUPERSET of patches in n. This is simply not true of 2.7 versus 3.2. 3.x is a fork off of 2.x at about 2.6. There are many 2.7-only bugs whose patches should not be forward ported, either 'by hand' or by auto

Re: [python-committers] branches are open

On 2/21/2011 1:11 PM, Georg Brandl wrote: py3k is now 3.3a0, Should that be 3.3.0a0, or does adding .0 come later? ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] New repositories

On 3/5/2011 9:30 AM, Georg Brandl wrote: On 05.03.2011 15:20, Georg Brandl wrote: On 05.03.2011 15:18, Antoine Pitrou wrote: Hello, Creation of the final hg repositories on hg.python.org is under way, so please no test commits anymore. And since testing things out if you're new to

Re: [python-committers] Recording committer status in the bug tracker

On 3/16/2011 12:18 AM, Eli Bendersky wrote: On Wed, Mar 16, 2011 at 06:09, Fred Drake fdr...@acm.org mailto:fdr...@acm.org wrote: On Tue, Mar 15, 2011 at 11:22 PM, Martin v. Löwis mar...@v.loewis.de mailto:mar...@v.loewis.de wrote: added a boolean flag to the bug tracker

Re: [python-committers] There are two versions of the Contributor Agreement

On 3/23/2011 9:31 PM, Victor Stinner wrote: http://www.python.org/psf/contrib/contrib-form-python/ and http://www.python.org/psf/contrib/contrib-form/ It looks like the first one is old, because http://www.python.org/psf/contrib/ points to the second one. I believe you are right. The only

Re: [python-committers] Committer rights for Nadeem Vawda

On 4/3/2011 11:17 AM, Antoine Pitrou wrote: I'd like to propose giving committer rights to Nadeem Vawda. He has submitted a number of patches since the beginning of the year, culminating with a complete rewrite of BZ2File in pure Python allowing to add new features (such as the support for

Re: [python-committers] Committer rights for Sandro Tosi

On 7/31/2011 12:53 PM, Ezio Melotti wrote: I would like to have Sandro added to the list of committers. Good. He has been very active on the bug tracker, doing triaging work and contributing a number of patches. After noticing his activity, I believe I counted over 30 patch submissions

Re: [python-committers] Three wishes for Mercurial-Roundup integration

On 8/31/2011 10:39 AM, Éric Araujo wrote: 1) When a commit message references more than one bug (with text matching #\d+), only the first gets a message for the changeset. I would like all referenced bugs to get a message. +1 I would have expected this to be the case already. While there is

Re: [python-committers] Contributor Agreement - David Tudor

On 5/16/2012 7:26 AM, Łukasz Langa wrote: Some words of explanation. David Tudor specifically is not a contributor, neither is Krzysztof Dąbrowski. Those are representatives of the company. This is my employer and it was my explicit will that the company signs an agreement implicitly for its

Re: [python-committers] Commit privileges for Chris Jerdonek

On 9/23/2012 1:23 PM, Mark Dickinson wrote: On Sun, Sep 23, 2012 at 6:20 PM, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, I would like to propose Chris Jerdonek as a new core developer. +1 +1 also. I have recently been thinking that it was about time.

Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)

On 9/30/2012 10:29 PM, Jesus Cea wrote: So, if I understand correctly, the current situation is this: 2.6: Security fixes only 2.7, 3.2, 3.3: Bugfixes only 2.3, 2.4, 2.5, 3.0, 3.1: Dead After 3.2.4 is published (soon), 3.2 would move to security fixes only. Am I right? I wonder if we have

Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)

On 10/1/2012 8:23 AM, Georg Brandl wrote: On 10/01/2012 01:30 PM, Martin v. Löwis wrote: Is there a PEP with end-of-life info? I had meant to write a PEP on security releases for several years now. Since this still doesn't exist, here is the outline of the procedures that maintainers have

Re: [python-committers] 3.3.1 two months away?

On 10/1/2012 1:02 AM, Georg Brandl wrote: You are right that we should have information about bugfix/security mode and about end-of-life; I propose to put them in the respective release schedule PEPs. From the commit: +3.3 will receive bugfix updates approximately every 4-6 months until

Re: [python-committers] Commit privs for Serhiy Storchaka?

On 12/25/2012 11:51 AM, Andrew Svetlov wrote: On Tue, Dec 25, 2012 at 6:38 PM, Mark Dickinson dicki...@gmail.com wrote: On Mon, Dec 24, 2012 at 5:07 PM, Trent Nelson tr...@snakebite.org wrote: He's pretty active on IRC and the tracker. I haven't dealt with any of his patches

Re: [python-committers] Anatoly Techtonik's contribution

This is a continuation of my answer to Christian On 12/25/2012 5:56 PM, Łukasz Langa wrote: Dnia 25 gru 2012 o godz. 13:37 Nick Coghlan ncogh...@gmail.com napisał(a): I'm well and truly to the point of caring far more about the feelings of people who get frustrated trying to deal with his

Re: [python-committers] Relicensing source code for inclusion in Python

On 4/4/2013 12:53 PM, M.-A. Lemburg wrote: On 04.04.2013 18:30, Antoine Pitrou wrote: Hello, In http://bugs.python.org/issue17618, I proposed adding a base85 implementation to Python. Mercurial already has one (under the GPL), so I wrote to the authors (Brendan Cully and Mads Kiilerich) and

Re: [python-committers] Commit rights to Ethan Furman

On 5/8/2013 4:44 PM, Eli Bendersky wrote: So I guess I can move forward with this unless there are objections in the next day or two, I have not responded before since Guido's approval seems sufficient ;-). The main concrete step is that one of the repository supervisors add his access key.

Re: [python-committers] what's going on with Misc/NEWS?

On 5/24/2013 8:24 AM, Brett Cannon wrote: I was trying to do a simple merge of a doc change between 3.3 and default and the usual Misc/NEWS conflict came up. I have had things like this happen and after pain iwth kdiff3 just edited the default version But when I looked at the diff it was

Re: [python-committers] what's going on with Misc/NEWS?

On 5/24/2013 9:00 AM, Nick Coghlan wrote: On Fri, May 24, 2013 at 10:24 PM, Brett Cannon br...@python.org wrote: would be great. And maybe it's finally time to bite the bullet and come up with some way to automatically generate Misc/NEWS from commit messages. No, commit messages do not a NEWS

Re: [python-committers] what's going on with Misc/NEWS?

Another replay that did not show up on list. On 5/24/2013 9:00 AM, Nick Coghlan wrote: On Fri, May 24, 2013 at 10:24 PM, Brett Cannon br...@python.org wrote: would be great. And maybe it's finally time to bite the bullet and come up with some way to automatically generate Misc/NEWS from commit

Re: [python-committers] hg clone cpython newrepo aborts

On 5/28/2013 4:50 PM, Ezio Melotti wrote: On Tue, May 28, 2013 at 9:47 PM, Terry Reedy tjre...@udel.edu wrote: On 5/28/2013 10:19 AM, Dirkjan Ochtman wrote: It's possible something broke with the @-filename. I am planning to change '@' to '_' anyway. What's wrong with just README

Re: [python-committers] hg clone cpython newrepo aborts

On 5/28/2013 7:23 PM, Guido van Rossum wrote: On Tue, May 28, 2013 at 3:00 PM, Terry Reedy tjre...@udel.edu wrote: As I said on the issue and in response to Benjamin's question, I prefer to have it appear near the top of the directory listing even when other non 'test_xxx' files are added. I

Re: [python-committers] IMPORTANT: Strip your repos if you pulled recently

On 7/15/2013 11:46 PM, Benjamin Peterson wrote: If you have c3a510b22218 in your repo, you will need to strip it like this $ hg strip c3a510b22218 (make sure to have the mq extension enabled) Does the subject mean that if I have not pulled recently (a day, at least), it will not get

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

On 11/29/2013 2:59 PM, Antoine Pitrou wrote: Then I don't know where his behaviour is most problematic: on the tracker or the MLs? If we only ban him from the tracker, I'm afraid he'll start making here's an issue I can't post on the tracker because I'm banned posts on the mailing-list...

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

On 11/29/2013 9:56 PM, Antoine Pitrou wrote: On ven., 2013-11-29 at 20:01 -0500, Terry Reedy wrote: I think an appropriate first signal would be to make it so he cannot change headers. I wasn't thinking only about the bug tracker, but also the MLs. Right, you are worried about retaliation

Re: [python-committers] Adding a (small) feature to 3.4 for Argument Clinic: inspect.Signature supporting simple named constants for default values

On 1/6/2014 5:21 PM, Barry Warsaw wrote: FWIW, this would probably be better on python-dev, but maybe you wanted to cut down on potential noise and churn? Better here, I think. On Jan 06, 2014, at 01:34 PM, Larry Hastings wrote: The thing is, I feel like this is borderline between bug fix

Re: [python-committers] clinic churn after beta2

On 1/7/2014 9:35 PM, Larry Hastings wrote: On 01/07/2014 06:06 PM, Nick Coghlan wrote: Addressing the key remaining barriers to migration for existing Python 2 users would be an excellent objective to attain before we end upstream support for Python 2.7, but it's one that would be better

Re: [python-committers] Updated schedule for Python 3.4

On 1/17/2014 6:27 AM, Nick Coghlan wrote: On 17 Jan 2014 12:03, Kristján Valur Jónsson krist...@ccpgames.com mailto:krist...@ccpgames.com wrote: And while I completely understand that core developers enjoy working in 3 much more, it was decided to not accept any improvements for a +2.7

Re: [python-committers] Commit access for Yury Selivanov?

On 1/19/2014 1:30 AM, Nick Coghlan wrote: Hi, I'd like to suggest granting commit access to Yury Selivanov, primarily to assist with maintenance of the inspect module. That's currently an orphaned module in the experts index, and Yury was a driving force behind getting PEP 362 (the new

Re: [python-committers] PEP 462: Workflow automation for CPython

On 1/25/2014 2:55 PM, Antoine Pitrou wrote: On sam., 2014-01-25 at 06:35 -0800, Eli Bendersky wrote: On Sat, Jan 25, 2014 at 6:14 AM, R. David Murray rdmur...@bitdance.com wrote: On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky eli...@gmail.com wrote: do the latter

Re: [python-committers] PEP 462: Workflow automation for CPython

On 1/25/2014 9:54 AM, Dirkjan Ochtman wrote: On Sat, Jan 25, 2014 at 2:49 PM, Eli Bendersky eli...@gmail.com wrote: Interesting. Chromium has something kind-of similar, named commit queue, for developers without actual commit access. Once they get an LGTM, the thing rolls automatically. In

Re: [python-committers] PEP 450: Commit access for Steven D'Aprano?

On 2/1/2014 8:02 PM, Nick Coghlan wrote: When PEP 450 (the statistics module) was accepted, it looks like we missed the step of granting Steven commit access for module maintenance purposes. We should probably fix that :) If we do, he might get sucked into working on other things ;-).

Re: [python-committers] default hg.python.org/cpython is now 3.5

On 3/17/2014 11:42 AM, Jesus Cea wrote: On 17/03/14 09:51, Victor Stinner wrote: Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only accept security fixes, right? Tradition says that until release *.1 is published. That is, 3.4.1 in this case. According to my memory,

Re: [python-committers] Small change to tracker 'resolution'

On 4/15/2014 8:55 PM, R. David Murray wrote: In a discussion at the sprints today Nick observed that 'invalid' was a resolution that carried a rather negative subtext (your bug report was invalid, ie: you made a mistake) , and that Red Hat used 'not a bug', which we all agreed was much more

Re: [python-committers] Small change to tracker 'resolution'

On 4/15/2014 9:45 PM, Ethan Furman wrote: On 04/15/2014 05:55 PM, R. David Murray wrote: [...] I've changed the text associated with the 'invalid' resolution to read 'not a bug' [...] Nice. Any chance of changing the 'committed/rejected' text to something else? :) Like 'finished'?

Re: [python-committers] New mailing list for workflow/workflow infrastructure discussion/tasks

On 4/16/2014 4:49 PM, R. David Murray wrote: Apologies for the cross post, but I want to make sure committers who aren't reading python-dev for one reason or another see this: Based on a number of conversations at PyCon, we've created a new mailing list:

Re: [python-committers] Proposing Berker Peksag for push privileges

On 6/15/2014 8:21 PM, R. David Murray wrote: I'd like to propose that we give Berker Peksag push privileges. He's provided a number of good quality patches and done good review work on other issues, and has been an active contributor for quite some time. IMO we've reached the point where it

Re: [python-committers] new hg.python.org server

On 9/12/2014 8:34 PM, Benjamin Peterson wrote: I just switched hg.python.org from a OSUOSL VM to a Rackspace VM. The new VM is a bit beefier and has what I think is better network connectivity, so hopefully that will improving the speed of repository operations. We also now support HTTPS for

Re: [python-committers] [RELEASE] Python 3.4.2rc1 is now available

On 9/22/2014 10:15 AM, Larry Hastings wrote: On behalf of the Python development community and the Python 3.4 release team, I'm chuffed to announce the availability of Python 3.4.2rc1. Python 3.4.2 has many bugfixes and other small improvements over 3.4.1. One new feature for Mac OS X users:

Re: [python-committers] [RELEASE] Python 3.4.2rc1 is now available

On 9/22/2014 2:12 PM, Ned Deily wrote: In article lvpkn3$mb4$1...@ger.gmane.org, Terry Reedy tjre...@udel.edu wrote: On 9/22/2014 10:15 AM, Larry Hastings wrote: On behalf of the Python development community and the Python 3.4 release team, I'm chuffed to announce the availability of Python

Re: [python-committers] Mark Lawrence

On 10/5/2014 2:47 PM, Benjamin Peterson wrote: On Sun, Oct 5, 2014, at 14:42, Serhiy Storchaka wrote: On 05.10.14 21:15, Benjamin Peterson wrote: BreamoreBoy is back on tracker touching hundreds of issues without adding any new information. This is certainly not the first time. Can we ban him?

Re: [python-committers] Mark Lawrence

On 10/5/2014 3:39 PM, Terry Reedy wrote: I responded on the issue, and will say more privately. I wrote him and tried to communicate three ideas. 1. Closing issues and responding to new messages, while important, are subsidiary to the primary goal of improving Python. 2. We would prefer more

Re: [python-committers] cherry picking after rc

On 10/6/2014 1:15 AM, Nick Coghlan wrote: On 6 October 2014 13:17, Larry Hastings la...@hastings.org wrote: I also didn't want to add another RC and slip the release--Matthias said he wanted to ship 3.4.2 with Ubuntu 14.10, but with their release only about two weeks away I didn't want to

Re: [python-committers] Mark Lawrence

On 10/6/2014 1:02 AM, Nick Coghlan wrote: On 6 October 2014 07:22, Terry Reedy tjre...@udel.edu wrote: On 10/5/2014 3:39 PM, Terry Reedy wrote: I responded on the issue, and will say more privately. I wrote him and tried to communicate three ideas. 1. Closing issues and responding to new

Re: [python-committers] [RELEASE] Python 3.4.2 is now available

On 10/8/2014 4:57 AM, Larry Hastings wrote: On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.2. Python 3.4.2 has many bugfixes and other small improvements over 3.4.1. One new feature for Mac OS X users: the

Re: [python-committers] Can we clean up the buildbots please?

On 5/22/2015 6:53 PM, Larry Hastings wrote: I'll answer my own question here. According to PCbuild/readme.txt: This script will use the env.bat script to detect one of Visual Studio 2015, 2013, 2012, or 2010, any of which may be used to build Python, though only Visual Studio 2015

Re: [python-committers] How are we merging forward from the Bitbucket 3.5 repo?

On 8/16/2015 3:13 AM, Larry Hastings wrote: So far I've accepted two pull requests into bitbucket.com/larry/cpython350 in the 3.5 branch, what will become 3.5.0rc2. As usual, it's the contributor's responsibility to merge forward; if their checkin goes in to 3.5, it's their responsibility to

Re: [python-committers] Gratuitous? incompatibilities in the fix only releases

On 7/29/2015 1:01 PM, Robert Collins wrote: On 30 July 2015 at 04:50, Guido van Rossum gu...@python.org wrote: I believe that in this particular case, the bug was fixed (by tightening the requirements for headers) because the bug can lead to security vulnerabilities. I think you can find more

Re: [python-committers] PSA: replace your DSA keys for SSH

. To you, my email address is my id. Fortunately, next release is at least 2 weeks off. On Thu, 8 Oct 2015 at 10:19 Tim Peters <tim.pet...@gmail.com <mailto:tim.pet...@gmail.com>> wrote: [Terry Reedy <tjre...@udel.edu <mailto:tjre...@udel.edu>>, on SSH keys] > I se

Re: [python-committers] How To Forward-Merge Your Change After Your Pull Request Is Accepted Into Python 3.5.0rcX

On 8/27/2015 3:32 PM, Larry Hastings wrote: Now that we're in the release candidate phase of Python 3.5.0, the workflow has changed a little. We're trying an experiment using Bitbucket and pull requests. You can read about that workflow, here:

Re: [python-committers] Python 3.6 Release Schedule Details

On 10/2/2015 3:41 PM, Ned Deily wrote: On Oct 2, 2015, at 10:20, R. David Murray wrote: On Thu, 01 Oct 2015 22:24:18 -0400, Ned Deily wrote: Another change has been to add a fourth beta and drop the third release candidate. My gut feeling from the past

Re: [python-committers] Release schedule for 3.4.4

On 11/22/2015 3:12 AM, Larry Hastings wrote: Sorry for the short notice of this schedule, but... here goes: Sat Dec 05 - tag 3.4.4rc1 Sun Dec 06 - release 3.4.4rc1 Sat Dec 19 - tag 3.4.4 final Sun Dec 20 - release 3.4.4 final This is exactly what I inferred when you said 'a

Re: [python-committers] bugs.python.org, job status, and contributors (aka not core devs)

> On Mon, Jun 6, 2016, 09:40 Ethan Furman > wrote: > >> Question: I noticed a couple issues on b.p.o that were being >> closed by contributors (not core-devs, not their own issues). >> Should non-core-devs be closing issues that do not belong to

Re: [python-committers] bugs.python.org, job status, and contributors (aka not core devs)

On 6/12/2016 8:24 PM, Larry Hastings wrote: On 06/06/2016 10:56 AM, Terry Reedy wrote: I have wondered whether triagers should have a symbol after their name -- perhaps &. I smell an assumption of ASCII, Unconscious, but yes. when presumably all of Unicode lay open at our feet. A

Re: [python-committers] Deprecation Policy PEP

On 1/30/2016 3:39 AM, Nick Coghlan wrote: Me too, but only if you add a PendingDeprecationWarning to PendingDeprecationWarning . There were some discussions a while back of restoring a distinction between the two by having code executed directly at the REPL (whether at the command line or in

Re: [python-committers] Making the PSF CoC apply to core developers

On 2/28/2016 3:56 PM, Victor Stinner wrote: Hi, 2016-02-26 20:29 GMT+01:00 Brett Cannon : I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC (https://docs.python.org/devguide/coredev.html and

Re: [python-committers] CFFI is slow

On 3/5/2016 4:31 AM, Larry Hastings wrote: 2. How important is this speed difference? I believe Pygame originally used SWIG or something similar to wrap the underlying C SDL library. When a ctypes version was tried, it was much slower, so slow that they stayed with the original wrapping.

Re: [python-committers] [Core-mentorship] Regarding reviewing test cases written for tabnanny module

On 4/11/2017 1:21 PM, Donald Stufft wrote: On Apr 11, 2017, at 12:25 PM, Terry Reedy <tjre...@udel.edu <mailto:tjre...@udel.edu>> wrote: I was under the impression that the green [commit] button would do the squashing. Or at least that it could. Yes it can, and IIRC for CPy

Re: [python-committers] [Core-mentorship] Regarding reviewing test cases written for tabnanny module

On 4/10/2017 11:55 PM, Martin Panter wrote: On 11 April 2017 at 13:13, Mariatta Wijaya wrote: "View Changes" doesn't work when commits in PR were squashed, which seems to be the case in https://github.com/python/cpython/pull/851 I wonder if there is a way to

Re: [python-committers] Spurious bugs.p.o messages

On 3/31/2017 6:08 PM, Brett Cannon wrote: On Fri, 31 Mar 2017 at 12:37 Victor Stinner > wrote: 2017-03-31 20:30 GMT+02:00 Antoine Pitrou >: > Just a heads up that the

Re: [python-committers] Spurious bugs.p.o messages

On 3/31/2017 8:20 PM, Ezio Melotti wrote: On Fri, Mar 31, 2017 at 3:59 PM, Terry Reedy <tjre...@udel.edu> wrote: On 3/31/2017 6:08 PM, Brett Cannon wrote: On Fri, 31 Mar 2017 at 12:37 Victor Stinner <victor.stin...@gmail.com <mailto:victor.stin...@gmail.com>> wrote:

Re: [python-committers] Deprecation Policy PEP Thread

On 4/9/2017 3:09 PM, Senthil Kumaran wrote: I was looking for our Deprecation Policy and stumbled on this thread from January 2016. - PEP: XXX Title: Deprecation Policy Version: $Revision$ Last-Modified: $Date$ Author: Ezio Melotti Status: Draft Type: Process Content-Type: text/x-rst

Re: [python-committers] 3.6.1 release status and plans

On 3/7/2017 8:59 PM, Ned Deily wrote: An update on the 3.6.1 release: As you probably noticed, 3.6.1 release candidate 1 was made available (finally!) two days ago. Thank you for your patience as we worked though the details of producing a release using our new GitHub-based development

[python-committers] Please briefly explain reverts in commit message

I read commit messages to learn from others and understand the CPython development. There have been several recent revert commits with no explanation (that I can see) in the commit message. I would like to see at least something brief. Some possibilities I can think of: Accidentally pushed

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

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

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

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

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

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,

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

Re: [python-committers] Codecov and PR

On 4/25/2017 11:00 AM, Barry Warsaw wrote: On Apr 24, 2017, at 09:32 PM, Ethan Furman wrote: On 04/21/2017 03:29 PM, Victor Stinner wrote: (In the context of having a patch blocked by the blind Codecov robot ...) I dislike code coverage because there is a temptation to write artificial

Re: [python-committers] Codecov and PR

On 4/26/2017 1:45 PM, Brett Cannon wrote: On Tue, 25 Apr 2017 at 17:00 Terry Reedy <tjre...@udel.edu <mailto:tjre...@udel.edu>> wrote: While I use code coverage to improve automated unittesting, I am opposed to turning a usable but limited and sometime faulty tool

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 advocating

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 <tjre...@udel.edu <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 e

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

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

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 <tjre...@udel.edu <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

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

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 :-)

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

[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

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)

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

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

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

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.

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 <tjre...@udel.edu> 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

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

branch? No. However, it 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 <tjre...@udel.edu>: I am getting repeated bogus failures, completely unr

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

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:

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

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

[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

  1   2   >