Re: [python-committers] Unapproved commits after 2.6.5rc1

2 other bugs without backporting to 2.6, I will do it for all my issues after the 2.6.5 release. -- Victor Stinner http://www.haypocalc.com/ ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python

Re: [python-committers] Python Language Summit at EuroPython

...). I live in France, I don't know yet if can come. But if I get an invitation, I have an excuse to come to EuroPython :-) -- Victor Stinner http://www.haypocalc.com/ ___ python-committers mailing list python-committers@python.org http

Re: [python-committers] svnmerge init on py3k branch fails..

to release26-maint. On py3k, the svn init gave the following problem. Why are you using svn init? It was already done in all branches. -- Victor Stinner http://www.haypocalc.com/ ___ python-committers mailing list python-committers@python.org http

Re: [python-committers] svnmerge init on py3k branch fails..

Le mardi 23 mars 2010 12:00:15, vous avez écrit : On Tue, Mar 23, 2010 at 3:57 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Why are you using svn init? It was already done in all branches. I had this understanding that, while using svnmerge.py you might to do one-time operation

Re: [python-committers] Untabifying the C codebase

) Is it documented somewhere? In the developer FAQ? -- Victor Stinner http://www.haypocalc.com/ ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Untabifying the C codebase

happy to see the curses module re-indented. Does anyone have a set of settings for Emacs or for GNU indent for Python's C indentation style? Done: revisions 81213, 81214-81216 I used untabify.py + emacs (python3 mode) + manual edit for Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS. -- Victor

Re: [python-committers] Delaying 3.2 release

patch is really huge: I cannot review it myself :-) I'm rewriting it from scratch to implement the right solution. Eg. My next patch will be on import to use the PyUnicodeObject* type instead of char*. I will open an issue for each patch. -- Victor Stinner http://www.haypocalc.com

Re: [python-committers] PEP checkin process

Le jeudi 22 juillet 2010 14:24:06, Antoine Pitrou a écrit : The PEP (numbered 3151) is now discussed on python-ideas. I like this PEP, great job Antoine! -- Victor Stinner http://www.haypocalc.com/ ___ python-committers mailing list python-committers

[python-committers] Partial commit privileges

Hi, The process to gain the commit priviledges is long, and it is sometimes difficult to decide if someone should have it or not. Would it be possible to have different levels of commit priviledes to simplify the process? Eg. first only be able to commit on a specific module, and then maybe more

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

Le mercredi 02 février 2011 à 11:47 -0500, Barry Warsaw a écrit : One issue it raises is the difficulties caused by freezing the trunk for releases. Instead they advocate creating the release branch at the point of the release candidate instead of freezing trunk. There are issues I currently

[python-committers] Create a Mercurial repository with a branch per issue

Hi, When a patch is attached to an issue, it is usually a patch for the last stable release or to trunk (2.7 or 3.2 trunk). The problem is that latter the patch doesn't apply to trunk anymore and the author have to update its patch. Sometimes, we ask to update a patch six months or one year after

Re: [python-committers] Create a Mercurial repository with a branch per issue

Le vendredi 04 février 2011 à 13:08 +0100, Jesus Cea a écrit : I support this, but implementation would be non trivial. Yes, it is non trivial, but it would be helpful :-) The problem is how to cope with security issues As I wrote: if security matters, only core developers should be able to

Re: [python-committers] Create a Mercurial repository with a branch per issue

Le vendredi 04 février 2011 à 14:48 +0100, Jesus Cea a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/11 14:31, Tarek Ziadé wrote: As a general rule, rebase should be done ONLY in personal clones not shared by anybody. Or, in this particular case, a clone should be

[python-committers] Use hg commit --user?

Hi, I do sometimes commit patches written by someone else. I tried to always add him/her to Misc/ACKS and in the changelog entry (Misc/NEWS). With git, it's possible to record an author different than the commiter. In Mercurial, I see a --user option. Can I use this option to commit a patch

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

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. Victor ___ python-committers mailing

[python-committers] Charles-François Natali (neologix)

Hi, This guy rocks! He understood and fixed many subtle bugs like race conditions recently. Example from the NEWS of Python 3.3: - Issue #12060: Use sig_atomic_t type and volatile keyword in the signal module. Patch written by Charles-François Natali. - Issue #11849: Make it more likely for

Re: [python-committers] Charles-François Natali (neologix)

Le dimanche 15 mai 2011 à 10:31 +0200, Victor Stinner a écrit : I would to propose him to commit grant. But I also propose to be his mentor: review all of his patches before commit. Victor ___ python-committers mailing list python-committers

Re: [python-committers] Charles-François Natali (neologix)

Le dimanche 15 mai 2011 à 10:31 +0200, Victor Stinner a écrit : I would to propose him to commit grant. What do you think? Including me, we have 4 votes for, none against. I asked him and he would like to become a Python developer. I will ask him for his SSH public key. Should he sign

Re: [python-committers] 3.2.1 rc 2

Le jeudi 19 mai 2011 à 20:33 +0200, Georg Brandl a écrit : As I've already said in another thread, I plan for 3.2.1 r2 as soon as http://bugs.python.org/issue12084 is fixed. This is hopefully this weekend, but may be next. Final is, as always, one week later. If I would like to touch Python

Re: [python-committers] 2.7.2 and 3.1.4 rc now

Le dimanche 29 mai 2011 22:55:17, Benjamin Peterson a écrit : Hi, I'm going to start spinning those releases now. I'll make a branch for 2.7.2 but not for 3.1.4. Please stop committing to 3.1; it's going into security only mode. Just to be sure, you mean the 3.1.4 will be the last bugfix

Re: [python-committers] 2.7.2 and 3.1.4 rc now

Le dimanche 29 mai 2011 22:55:17, Benjamin Peterson a écrit : Hi, I'm going to start spinning those releases now. I'll make a branch for 2.7.2 but not for 3.1.4. Please stop committing to 3.1; it's going into security only mode. I would like to commit something into the 2.7 branch. The NEWS

Re: [python-committers] 2.7.2 and 3.1.4 rc now

changeset: 70534:3b1b06570cf9 branch: 2.7 parent: 70509:439396b06416 user:Victor Stinner victor.stin...@haypocalc.com date:Mon May 30 23:44:13 2011 +0200 summary: Issue #12016: my_fgets() now always clears errors before calling fgets(). Fix the following case

Re: [python-committers] Python 3.2.1rc2

I'm starting to release 3.2.1 rc2 now. There are two stable buildbot failures that look legitimate I suppose that one of the failure was the issue #12467. The following commit fixed it in the 3.2 branch: New changeset ac18e70cbe7e by Victor Stinner in branch '3.2': Issue #12467: warnings: fix

Re: [python-committers] Commit rights for Meador Inge

Le 19/09/2011 04:11, Meador Inge a écrit : On Sun, Sep 18, 2011 at 6:03 PM, Brett Cannonbr...@python.org wrote: http://docs.python.org/devguide/coredev.html#gaining-commit-privileges I believe everything is in place: 1. I am subscribed to the right mailing lists. 2. I already had

Re: [python-committers] 3.3 rc1 next week

Why not creating a 3.3.0 branch to prepare the release instead of a different repository? Victor Le 19 août 2012 13:05, Georg Brandl g.bra...@gmx.net a écrit : Dear committers, if the buffer/array-related blockers are resolved in time, the rc1 will be released one week from now. Since some

Re: [python-committers] New core developer

Ok for me. Victor Le 23 août 2012 01:35, Antoine Pitrou solip...@pitrou.net a écrit : Hello, I'd like to propose Serhiy Storchaka as a new core developer. He has made numerous contributions, and has proven receptive to comments and reviews. He's also interested in becoming a core

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

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 Would it be possible to write this status in the devguide (and also maintain it!)? Victor ___

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

How do you perceive his contributions in general? He is really annoying. He is flooding python-ideas and python-dev lists with emails without trying to understand answers. He didn't understand that the Python community is not working for him. IMO he has a negative effect on the Python

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

Le mardi 25 décembre 2012, Christian Heimes a écrit : His attitude hasn't improved, too. For example in bug http://bugs.python.org/issue16689 he used an offensive title and re-opened the ticket *twice* although it was closed by two different and highly respectable core devs. Oh, I missed

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

2012/12/30 Meador Inge mead...@gmail.com: * WIlling to complain, but not help fix anything * Is this person draining attention and focus? * Is this person paralyzing the project? I don't understand how Anatoly plans to help Python with such project:

Re: [python-committers] Commit privileges for Roger Serwy for IDLE

It's maybe not the right place to discuss that, but why is IDLE part of the Python stdlib? Can't we maintain IDLE outside Python? I guess that maintaining it outside the stdlib would allow to develop it faster and be able to upgrade it for old (unmaintained) Python versions. Packaging Python with

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

2013/5/28 Senthil Kumaran sent...@uthcode.com While trying to clone a cpython repo to a new repo. I am getting this error. getting Lib/idlelib/idle.bat getting Lib/idlelib/idle.py getting Lib/idlelib/idle.pyw getting Lib/idlelib/idle_test/@README.txt abort:

Re: [python-committers] Reminder: Python 3.4 alpha 1 release is Saturday August 3

2013/7/25 Larry Hastings la...@hastings.org: It's about nine days from now. I expect to tag the release late next week. So if you're doing any major brain surgery, please finish it up in the next week or so. I hope that I would have enough free time before the alpĥa2 to: * find a consensus

Re: [python-committers] Reminder: Python 3.4 alpha 1 release is Saturday August 3

2013/8/2 Victor Stinner victor.stin...@gmail.com: 2013/7/25 Larry Hastings la...@hastings.org: It's about nine days from now. I expect to tag the release late next week. So if you're doing any major brain surgery, please finish it up in the next week or so. I hope that I would have enough

Re: [python-committers] [RELEASED] Python 3.4.0a2

2013/9/9 Larry Hastings la...@hastings.org: Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series so far include: * PEP 446, changing file descriptors to not be inherited

Re: [python-committers] [RELEASED] Python 3.4.0a2

2013/9/9 Antoine Pitrou solip...@pitrou.net: Le Mon, 9 Sep 2013 14:30:50 +0200, Victor Stinner victor.stin...@gmail.com a écrit : 2013/9/9 Larry Hastings la...@hastings.org: Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes

Re: [python-committers] I *might* push Python 3.4.0 alpha 4 back a week

2013/10/19 Larry Hastings la...@hastings.org: A lot has landed in trunk in the last day or two: Tulip, Argument Clinic, and statistics just landed too. Wow, Python 3.4 looks great! I was waiting for statistics. Don't forget to update the What's New in Python 3.4 document. Victor

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

Hi, I worked with many and various contributors on the Python projects last 3 years. All contributors made a lot of effort to understand the process (which is complex and not well documented), try to find information by themself (ask find the right place to ask questions like how can I find

Re: [python-committers] PyCon Language Summit: Wednesday 9th April

Hi, 2013/12/4 Michael Foord mich...@voidspace.org.uk: As with previous years we will be having a Language Summit at PyCon North America, in Montreal. The summit will be on Wednesday 9th April and running from approximately 10am to 4pm. My talk Track memory leaks in Python was accepted, I

Re: [python-committers] clinic churn after beta2

2014/1/7 Eli Bendersky eli...@gmail.com: Are we really that much in need of convert-to-clinic *now*? Why not creating the 3.4 branch after the beta1 and develop Python 3.5 in default during the stabilisation process of Python 3.4? It's like many other softwares are developed. Only bugfixes

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

Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only accept security fixes, right? Victor Le 17 mars 2014 07:48, Larry Hastings la...@hastings.org a écrit : The 3.4 branch is now checked in. It contains all the 3.4 releases since 3.4.0rc1. Its current state is

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

Hi, I modified the Misc/NEWS file: * I moved 3.3 sections to Misc/HISTORY: items were already present, but the format in Misc/NEWS was improved (changeset 6ba468d4fa96) * I removed 3.4.1 section: changes of 3.4 after 3.4.0 must already be present in the 3.4 branch (changeset cb161cd94e6e) Is

Re: [python-committers] [RELEASED] Python 3.4.1

It's not easy to find the changelog. I found this page: https://docs.python.org/3.4/whatsnew/changelog.html Victor 2014-05-19 8:00 GMT+02:00 Larry Hastings la...@hastings.org: On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the

[python-committers] Commit access to PEPs for Ben Hoyt

Hi, Ben Hoyt (benh...@gmail.com) is working on the os.scandir() PEP 471: http://legacy.python.org/dev/peps/pep-0471/ Currently, he send me the PEP text and I update the repository. Would it be possible to give him access to the repository directly? (only to the peps reposistory) Victor

Re: [python-committers] Proposed core developer for contributing to multiprocessing

Hi, 2015-01-07 9:51 GMT+01:00 Antoine Pitrou anto...@python.org: I would like to propose Davin Potts as core developer to take on the responsibility for maintaining the multiprocessing package. Did he already contributed to CPython? What is his nickname on the bug tracker? Can we see his

Re: [python-committers] HEADS UP!: There is no v3.4.3 tag in the repository

Oh, I just noticed that Larry merged his changes into the 3.4 branch. Problem: the 3.4 branch was not merged into default, and the merge creates conflicts. @Larry: Can you please fix this? (Merge 3.4 into default.) Victor 2015-02-26 14:04 GMT+01:00 Victor Stinner victor.stin...@gmail.com

Re: [python-committers] HEADS UP!: There is no v3.4.3 tag in the repository

Releases are done in a separated repository. Larry has to merge its private repository into the upstream 3.4 branch. Victor 2015-02-26 13:19 GMT+01:00 Jesus Cea j...@jcea.es: Current repository doesn't have a v3.4.3 tag. Please tag it and let me know when done :). Pay attention to tag the

Re: [python-committers] Do people prefer pushing feature repos or one massive patch?

: 87401:6e2089dbc5ad user:Victor Stinner victor.stin...@gmail.com date:Sat Nov 23 12:27:24 2013 +0100 files: Doc/library/debug.rst Doc/library/tracemalloc.rst Doc/license.rst Doc/using/cmd description: Issue #18874: Implement the PEP 454 (tracemalloc) Doc/library/debug.rst

Re: [python-committers] Do people prefer pushing feature repos or one massive patch?

If you choose to merge, I would prefer that you rebase your changes before to avoid multiple merges. IMO the best to avoid merges at all :-) Did someone review your large change? Victor 2015-04-01 18:09 GMT+02:00 Brett Cannon bcan...@gmail.com: The implementation for PEP 488 is basically done

Re: [python-committers] Promote Xavier de Gaye as a core developer

Le 2 juin 2016 20:32, "Antoine Pitrou" a écrit : > > > Le 02/06/2016 20:26, Brett Cannon a écrit : > > > > 1. Have him send me his preferred email address for python-committers > > 2. Make sure he has his github username listed on bugs.python.org > >

Re: [python-committers] Promote Xavier de Gaye as a core developer

2016-05-22 14:23 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > Cool, already three +1 (ignoring my own +1). I will wait until friday > to give time to other to give their opinion on Xavier's promotion. I counted 5 positive votes: * Victor Stinner * Zachary Ware * Georg Bra

Re: [python-committers] push to devguide: "abort: authorization failed"

Sorry for the noise, I used the wrong URL for the repository. In fact, the last time that I pushed a change, it was on another computer, so I was confused. I should use ssh://h...@hg.python.org/devguide to push ;-) Victor 2016-01-22 9:24 GMT+01:00 Victor Stinner <victor.stin...@gmail.com>

[python-committers] push to devguide: "abort: authorization failed"

Hi, I wanted to fix a small typo in the devguide, but I'm unable to push this morning. haypo@smithers$ hg push --debug pushing to https://hg.python.org/devguide/ using https://hg.python.org/devguide/ sending capabilities command hg.python.org certificate successfully verified query 1; heads

Re: [python-committers] Anyone up for a core dev panel discussion at EuroPython 2016 ?

Hi, 2016-02-19 17:35 GMT+01:00 M.-A. Lemburg : > No, seriously, this is great stuff normal Python users never get > to see and that's really a shame. This week, I wrote an article listing my contributions during 2015 Q3: https://haypo.github.io/contrib-cpython-2015q3.html On

Re: [python-committers] The state of our copies of libffi (was: Redoing the C API?)

Why starting many discussions on the private python-committers mailing list? Why not discussing libffi on python-dev? Victor ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code

Re: [python-committers] Redoing the C API? (was: Call For Participants For The 2016 Python Language Summit)

2016-03-03 18:39 GMT+01:00 Brett Cannon : > But I do think the spirit of Victor's idea is worth considering. Oh, another note about such theorical API. For CPython, it would be nice to experiment to implement such new API *on top* of the existing Python C API. And it should be a

Re: [python-committers] Call For Participants For The 2016 Python Language Summit

2016-03-02 2:01 GMT+01:00 Larry Hastings : > The purpose of the event is to disseminate information and spark > conversation among Python core developers. It's our once-a-year chance to > get together and hash out where we're going and what we're doing, > face-to-face. Sadly,

Re: [python-committers] Call For Participants For The 2016 Python Language Summit

2016-03-03 13:40 GMT+01:00 Nick Coghlan : > Adding cffi (including its dependencies) to the standard library was > approved-in-principle a couple of years ago, and I believe the one > technical issue with a lack of support for ahead-of-time compilation > of the extension module

Re: [python-committers] Tweaks to the Motivations & Affiliations page

I added myself to mention that my employer Red Hat gives me time to work on CPython. Victor 2016-04-24 6:49 GMT+02:00 Nick Coghlan : > Hi folks, > > I just pushed an update to the Motivations & Affiliations page in the > Developer Guide:

Re: [python-committers] Promote Xavier de Gaye as a core developer

2016-05-22 11:42 GMT+02:00 Stefan Krah : > +1. The Android patches are very good -- he would be the ideal maintainer. The Android work looks to become something serious. To make the Android support official, we need a buildbot, but let's discuss that on python-dev later ;-)

[python-committers] Promote Xavier de Gaye as a core developer

Hi, I propose to promote Xavier de Gaye as a Python core developer. I noticed that he is proposing good patches since a lot time ago (first one around 2010! issue #9250). He now looks to be motivated to help porting CPython to Android. IMHO it's a good thing to support this platform. It's a

[python-committers] Xavier de Gaye

Hi, Xavier de Gaye is a Python core developer since June 3, 2016. I just noticed that his grant wasn't logged in the devguide: it's now fixed (online doc not up to date yet): https://docs.python.org/devguide/developers.html#permissions-history Xavier already pushed some changes to enhance

Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit

2017-01-24 21:46 GMT+01:00 Neil Schemenauer : > Maybe we could emulate the Linux kernel releases. I.e. have > relatively fast moving development but also choose releases to give > long maintenance cycles. Ideally the long term releases would be > synchronized with OS

Re: [python-committers] Proposed new core developer -- Mariatta Wijaya

2017-01-26 14:49 GMT+01:00 Nick Coghlan : > With Raymond volunteering as mentor, I think an approach where changes > are still reviewed, but it's Mariatta that does the final commit would > work. > > That would be pretty similar to the way things worked when I > recommended

Re: [python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

2017-01-21 0:14 GMT+01:00 Andrew Dalke : > For this one bug, I agree with the interpretation that it was handled with a > cavalier attitude. I don't feel like it's being treated with the seriousness > it should. The regression was introduced by

Re: [python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

2017-01-21 20:51 GMT+01:00 Brett Cannon : > What I'm picking up from this is (as a gross oversimplification): > > * Victor _wants_ code reviews > * Raymond thinks we _need_ code reviews For a concrete example, I wrote a patch for a major regression in the datetime module at

[python-committers] Date of the Language Summit at Pycon US 2017?

Hi, I'm going to book my hotel and flight for Pycon US, but I don't know the date of the Language Summit and I would prefer to not miss it if possible :-) Does someone organize it? Victor ___ python-committers mailing list python-committers@python.org

[python-committers] Accept a PR but only push it once tests pass?

Hi, Would it be possible to modify the workflow of GitHub pull requests to allow to click on Merge, but only merge a PR once tests complete and only if tests pass? If some tests start to become too annoying for the pre-commit CI, we can try to fix them, or even disable them in the CI to only

[python-committers] New Roundup notifications on Git commits?

Hi, I merged my pull request: https://github.com/python/cpython/pull/12 which has a commit message starting with "bpo-29524: ", but the issue wasn't updated (no new comment to mention the comit): http://bugs.python.org/issue29524 The final commit is:

Re: [python-committers] Discussions on PRs

I prefer to discuss on the review rather than on the bug tracker. In the extreme case, if we had to choose, I had rather prefer to drop the bug tracker. It is not going to appear since people still have to report bugs without patch :-) Victor 2017-02-13 10:33 GMT+01:00 M.-A. Lemburg

[python-committers] Mercurial commit url is broken

Hi, I clicked on a Mercurial commit number from: http://bugs.python.org/issue18383#msg249581 It points me to: http://hg.python.org/lookup/c1396d28c440 ... which displays short error message: --- Usage: /lookup/GITHEXHASH or gitGITHEXHASH (10, 11, or 40 hex characters) /lookup/HGHEXNODE or

Re: [python-committers] New Roundup notifications on Git commits?

What and where is the meta-tracker? Is it http://github.com/python/core-workflow/? Victor 2017-02-16 6:33 GMT+01:00 Ezio Melotti <ezio.melo...@gmail.com>: > On Thu, Feb 16, 2017 at 2:10 AM, Victor Stinner > <victor.stin...@gmail.com> wrote:

Re: [python-committers] New Roundup notifications on Git commits?

> New changeset 72e81d00eee685cfe33aaddf2aa9feef2d07591f by Victor Stinner in > branch 'master': Ok, I confirm that I now get notifications. Cool :-) New request (!): would it be possible to mention the author instead of the commiter? Or maybe mention both? Thanks,

[python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

Hi, Raymond Hettinger used a regression that I introduced in the builtin sorted() function (in Python 3.6.0) to give me his feedback on my FASTCALL work, but also on Argument Clinic. Context: http://bugs.python.org/issue29327#msg285848 Since the reported issues is wider than just FASTCALL,

[python-committers] No more notifications of commits (merged PR) on bpo?

Hi, My PR was merged, but I don't see any notification on bpo: https://github.com/python/cpython/pull/253 http://bugs.python.org/issue27840 A few weeks ago, we got two notifications per commit (hg, git), and now there is zero notification :-) Is it a known issue? Victor

Re: [python-committers] autoconf 2.70

2016-09-12 8:27 GMT+02:00 Benjamin Peterson : > The correct way to solve this is probably to stop checking in the > generated configure Please keep it, it's convenient :-) > and generate it with a "blessed" autoconf version in the release tarballs. +1 for that: we should

Re: [python-committers] commit privileges for INADA Naoki

I wanted to propose the same thing, but I deferred this item of my TODO after the crazy 3.6 beta 1 :-) So a big +1 for Naoki! Yury: would you be his mentor? IMHO it is very helpful to have a dedicated mentor for the first weeks. By the way, I noticed that he seems to follow python-dev according

Re: [python-committers] commit privileges for INADA Naoki

https://docs.python.org/devguide/coredev.html gives some steps ;-) 2016-09-26 17:23 GMT+02:00 Yury Selivanov : > Thank you guys. I'll send a detailed email to INADA, explaining most > basic things (and a link to devguide). And sure thing, I'm OK with > mentoring. > > Who

Re: [python-committers] Greeting from INADA Naoki

Hi, It's nice to have you on board to take care of the new implementation of dict :-) Welcome! Since you are japanese and probably know well issues with encodings, it would be nice if you test Python 3.6, especially on Windows, to see if you see some potential issues and/or enhancements. Python

[python-committers] Promote Xiang Zhang as a core developer

Hi, Last months, I noticed that Xiang Zhang is very active on the bug tracker and propose many enhancements and bug fixes. He contributes to Python code, but also to the C code (a rare skill nowadays). Slowly, he understood how to produce "good" patches, the CPython workflow, etc. I think that

Re: [python-committers] 3.6 branch now open only for 3.6.0 release critical fixes and doc updates!

Ok, thank you Raymond for checking. Victor Le 23 nov. 2016 05:25, "Raymond Hettinger" <raymond.hettin...@gmail.com> a écrit : > > > On Nov 22, 2016, at 6:57 AM, Victor Stinner <victor.stin...@gmail.com> > wrote: > > > > Should I revert

Re: [python-committers] autoconf 2.70

2016-11-23 23:49 GMT+01:00 Gregory P. Smith : > The solution to your problem is to maintain your patches _only_ against > configure.ac and rerun autoconf using whatever version you need yourself. I agree :-) Victor ___

Re: [python-committers] 3.6 branch now open only for 3.6.0 release critical fixes and doc updates!

Hi, 2016-11-22 8:24 GMT+01:00 Ned Deily : > OK, all of the release engineering for 3.6.0b4 is complete. The 3.6 branch > in the cpython repo is now available again but, as noted, *only* for reviewed > release critical fixes appropriate for the 3.6.0 final and for final 3.6.0

[python-committers] New core developer: Xiang Zhang

Hi, We have a new core developer today, Xiang Zhang! He comes from China and is already very active in various area of the CPython soure code. He just got his commit bit. * commit bit: Brett added Xiang's key. Xiang already pushed a test commit, https://hg.python.org/test/rev/530f0afa8072 *

Re: [python-committers] autoconf 2.70

I know that tracking generated files is not pure, but it's very convenient, so please keep them: configure, Python/importlib.h, Python/importlib_external.h, etc.! When testing Python on some "custom" operating systems, I already had enough issues to compile Python :-) For example, on

Re: [python-committers] Promote Xiang Zhang as a core developer

2016-11-15 16:46 GMT+01:00 Senthil Kumaran : >> Maybe Xiang needs a longer mentoring period than 1 month, but I want >> to keep him motivated. Active contributors (even inside core >> developers) are rare, so we always need fresh blood :-) > > I agree with this statement. I

Re: [python-committers] Promote Xiang Zhang as a core developer

Hi, 2016-11-15 1:10 GMT+01:00 Berker Peksağ : > Xiang tends to fix things that are not broken, This sentence sounds strange. What do you mean? :-) > (...) and when you point out that the thing they are > trying to fix is not broken, they try to start an endless

Re: [python-committers] [Python-Dev] LAST CHANCE: 3.6.0 code freeze (3.6.0rc1) in 12 hours at 2016-12-07 12:00 UTC

Hi, Can someone please review my patch for the following issue? "Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)" http://bugs.python.org/issue28835 It would be nice to fix a known regression which has a patch :-) I added warnings._showwarnmsg() to

Re: [python-committers] commit privs given to Maciej Szulik for bugs.python.org work

2016-12-23 19:07 GMT+01:00 Brett Cannon : > Maciej has been helping Ezio, David, and me out with updates to > bugs.python.org for the GitHub migration and he's reached a point where we > are all comfortable with him making updates to the issue tracker's code > without us holding

Re: [python-committers] commit privs given to Maciej Szulik for bugs.python.org work

https://hg.python.org/tracker/ Ah ok, no problem if it's only for this repository. (+1) Victor ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct:

Re: [python-committers] Is clang testing necessary?

Even if for most changes, testing gcc and clang is useless, I'm in favor of keeping both for the CI. It doesn't cost much, and it's not that uncommon that Clang catchs bugs or warnings, than GCC doesn't. The question is more who checks for compiler warnings in the CI :-) Currently, you have to

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

2017-03-31 20:30 GMT+02:00 Antoine Pitrou : > Just a heads up that the following PR: > https://github.com/python/cpython/pull/552/files > has generated a lot of spurious PR additions on bugs.python.org, > probably because that PR references a lot of issues > (example:

Re: [python-committers] Codecov and PR

Oh, I forgot something about Codecov: it took me 2 minutes to understand why a PR gets the red icon whereas all tests pass and the merge button was waiting for my click. In fact, Codecov failed but the test isn't blocking. I would expect the green icon on the overall list of PR. Well, it's not

Re: [python-committers] Codecov and PR

Thank you, I will take a look and see if I can help. Victor Le 22 avr. 2017 6:43 PM, "Brett Cannon" <br...@python.org> a écrit : > > > On Fri, 21 Apr 2017 at 15:33 Victor Stinner <victor.stin...@gmail.com> > wrote: > >> Ah, I found a workaround: Fir

Re: [python-committers] New ncoghlan-bpo-29537-NEWS branch?

Le 9 mars 2017 7:32 PM, "Brett Cannon" a écrit : In general I expect none of those branches to live longer than 24 hours as the PRs they were created for should be merged in less than an hour. If a branch is older than a day then it means someone probably forgot to delete the

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

> Ned, 7 tests fail for me on Windows. I believe 3.6.0 ran clean or nearly > so. Pasteing below is best I can do right now as I had eye operation less > than 24 hours ago. It's an issue with newlines and Git which only impact tests: http://bugs.python.org/issue29530 Victor

[python-committers] GitHub: allow Rebase and merge

Hi, Would it be possible to keep "Squash and merge" button by default on GitHub pull requests, but allow "Rebase and merge" to keep multiple commits when they are well written. Example of such PR: https://github.com/python/cpython/pull/489/commits Maybe the second commit lacks bpo-xxx, but it's

Re: [python-committers] Please Publicize your Github Membership for Python

Donald just merged a change to not restrict mention-bot to members of the GitHub Python organization: https://github.com/python/cpython/pull/393 Victor 2017-03-03 8:03 GMT+01:00 Nick Coghlan : > On 2 March 2017 at 23:20, Donald Stufft wrote: >> >> Hello! >>

Re: [python-committers] UPDATE 1: Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California

I created https://public.etherpad-mozilla.org/p/cpython-dev-sprint-2017 etherpad to organize the sprint. Feel free to write whatever you want about the sprint there ;-) I started to list project ideas. Victor 2017-07-12 13:55 GMT+02:00 Łukasz Langa : > Update: the sprint is on!

Re: [python-committers] GitHub: remove the "needs backport to 3.5" label?

2017 12:04 PM, "Brett Cannon" <br...@python.org> wrote: >> >>> No one has said anything, so I will delete the label sometime today. >>> >>> On Wed, 9 Aug 2017 at 12:20 Brett Cannon <br...@python.org> wrote: >>> >>>> On

  1   2   3   4   5   >