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

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

2017-07-14 20:33 GMT+02:00 Brett Cannon : > In preparation of fully moving over to blurb and per-file news entries (I > don't have an ETA from Larry on when he plans to do explode Misc/NEWS into > individual files), ... Oh, I wasn't aware of this plan. What is the benefit of

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

2017-07-10 17:35 GMT+02:00 Guido van Rossum : > Often the committer has more context to write a proper commit message, and > asking the contributor to do the squash is just wasting time (plus in > general we *don't* want contributors to squash, since that loses the context > for

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

I removed the "CLA not signed" and automatically, the label "CLA signed" appears in 2 seconds ;-) Have a nice day. Victor 2017-07-18 11:34 GMT+02:00 Antoine Pitrou : > > Hi, > > How can I get the CLA bot to fix its knowledge for a particular contributor? > > bugs.python.org

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

Hi, 2017-07-18 11:36 GMT+02:00 Antoine Pitrou : > Can I take the opportunity to say thank you again (both you and Larry) > for the "blurb" tool? It really makes an important difference when > contributing. > > Regards > > Antoine. I concur with Antoine, I'm now *very* happy

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

I would prefer to ask the author to squash and/or rebase his/her commits rather than having to edit the commit message myself. I prefer that the commit message is part of the review, and not only done by the one who clicks on the Merge button. It would prefer mistakes in the commit message.

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

2017-07-16 16:10 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > What is the benefit of converting old Misc/NEWS entries? I guess that the benefit is to use a single format for all NEWS entries. I understand that it will ease the build of the changelog. > Do you have an idea o

[python-committers] Dismiss review if a PR is modified

2017-07-18 21:21 GMT+02:00 R. David Murray <rdmur...@bitdance.com>: > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner <victor.stin...@gmail.com> > wrote: >> I'm just not unconfortable with the fact that an approval is kept even >> if the PR is modified after

Re: [python-committers] Dismiss review if a PR is modified

annon" <br...@python.org> a écrit : On Tue, 18 Jul 2017 at 13:10 Victor Stinner <victor.stin...@gmail.com> wrote: > 2017-07-18 21:21 GMT+02:00 R. David Murray <rdmur...@bitdance.com>: > > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner < > vic

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

2017-07-19 17:23 GMT+02:00 Barry Warsaw : > That, and bringing back the diamond operator for realz. For people who don't know the "diamond operator" like me ;-) haypo@selma$ python3 Python 3.5.3 (default, May 10 2017, 15:05:55) >>> from __future__ import barry_as_FLUFL >>> 1 !=

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

2017-07-26 4:22 GMT+02:00 Brett Cannon : > So are you requesting we stop building on AppVeyor? No. I would like to know how to fix the AppVeyor issue :-) Is it a bug under our control? Victor ___ python-committers mailing list

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

Technically, "make regen-all" doesn't use the freshly built Python. It uses PYTHON_FOR_REGEN which is usually "python3". Victor 2017-07-24 15:48 GMT+02:00 Nick Coghlan <ncogh...@gmail.com>: > On 24 July 2017 at 18:55, Victor Stinner <victor.stin...@gmail.com>

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

vis CI. If we move the test in a GCC job, it would allow to check regen and GCC warnings in the same job. Victor 2017-07-24 12:16 GMT+02:00 Antoine Pitrou <anto...@python.org>: > > Le 24/07/2017 à 10:55, Victor Stinner a écrit : >> IMHO everything is fine and we don't have t

Re: [python-committers] Un-available till End of August -2017

Welcome back ;-) Victor Le 22 juil. 2017 4:09 AM, "Senthil Kumaran" a écrit : > Hello Python Committers, > > I have been inactive (unsubscribed from all python.org) mailing list > since May 2017. > > I had some study / other commitments that took too much time and I

Re: [python-committers] [Python-Dev] 3.6.2 update: 3.6.2rc2 coming

2017-07-03 6:43 GMT+02:00 Ned Deily : > Expect to see 3.6.2rc2 available within the next couple of days (2017-07-04 > expected) and, assuming no new issues, 3.6.2 final about a week later (around > 2017-07-11). Any update on 3.6.2rc2? I would like to check if

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

! The slowest time on some buildbots. I don't know much more at this point. Please join http://bugs.python.org/issue30822 if you want to help fixing this issue ;-) Victor 2017-06-14 16:40 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > Hi, > > The CPython workflow was enhanced to

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

2017-07-05 15:51 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > 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

Re: [python-committers] Travis now checks for whitespace issues in PRs

FYI PC/pyconfig.h couldn't be modified in the master branch, because it contains tabs. See https://github.com/python/cpython/pull/2476 failure. I created https://github.com/python/cpython/pull/2477 which contains a "make patchcheck" run to reformat PC/pyconfig.h. Maybe we should fix spaces of all

Re: [python-committers] Codecov and PR

`self.initfp()` is very unlikely raise exceptions. But MemoryError, KeyboardInterrupt or other rare exceptions may be happen. unittest.mock helps a lot to test such corner case: mock initfp() with a MemoryError side effect, maybe also close () to check that the method was called... The new

[python-committers] Codecov and PR

Hi, I tried to merge a pull request on my phone, but I got the error: "Pull requests that have a failing status can’t be merged on a phone." The GitHub PEP announced that it will be possible to merge a change from the beach. Well, it's doable but only if you bring a laptop, not a phone :-) All

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

Hi, Python 3.5 entered security fix only mode. Should we now remove the "needs backport to 3.5" label? Other security only branches don't have this label neither (3.3 and 3.4). Victor ___ python-committers mailing list python-committers@python.org

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

spams Travis CI which has to abort running jobs, and then restarts new jobs from scratch. $ git log commit dc72f12b877cacdc3746e152a9379f4c3083fa22 <= my change Author: Victor Stinner <victor.stin...@gmail.com> Date: Wed Jul 26 02:20:55 2017 +0200 bpo-30778: Skip test_bsddb3

[python-committers] Feedback on the new CPython workflow

Hi, I wanted to wait a little bit before giving back my feedback on the new workflow. I just attend Brett Canon's talk at the Language Summit. So here are my misc notes on the new workflow. * Is there anyone already working on the workflow who would like to get a grant (money!) from the PSF? *

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

Does it allow catch for 3.3 and 3.4 branches? I got notifications for 3.6, 3.5 and 2.7 backports of https://github.com/python/cpython/pull/1849 but not for the 3.3 and 3.4 backports: https://github.com/python/cpython/pull/2291 https://github.com/python/cpython/pull/2292 These two backports have

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

2017-06-26 16:47 GMT+02:00 Antoine Pitrou : > Just kill the job :-) See my first email: first, I killed the macOS job, and then Travis CI was marked as failed on PR, and so my PR couldn't be merged... Victor ___ python-committers

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

48 minutes later: the macOS is running for 33 minutes, but Travis CI fails to retrieve the logs :-/ https://travis-ci.org/python/cpython/jobs/247090627 Victor 2017-06-26 15:57 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > Hi, > > I was waiting for the result of Travis CI:

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

2017-06-26 17:25 GMT+02:00 Antoine Pitrou : > Given that it doesn't hurt to keep it, I would rather keep it. It > allows to quickly test for OS X-specific issues. According to my bad experience of today, it took longer than 1h30 to get the [Merge] button... Before, it took

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

ost-commit jobs on buildbots, no? Victor 2017-06-26 16:46 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > 48 minutes later: the macOS is running for 33 minutes, but Travis CI > fails to retrieve the logs :-/ > https://travis-ci.org/python/cpython/jobs/247090627 > > Victor

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

Hi, I was waiting for the result of Travis CI: 3 jobs already completed, but the macOS job was still running. The macOS job is marked as "allowed failure". I cancelled the job, but then the Travis CI was marked as failed in the PR :-/ So I restarted the job. Is it normal to have to wait for the

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

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, but only security

Re: [python-committers] [Python-Dev] Proposed release schedule for Python 3.5.4

2017-06-23 15:19 GMT+02:00 Larry Hastings : > Do you need write access to the branch in order to get Travis CI working? As soon as someone reviews my proposed 3.4 patches, no :-) I will work on a PR. Victor ___ python-committers

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

2017-06-27 18:33 GMT+02:00 Antoine Pitrou : > I see this sporadically on another project. There was no configuration > change, it just seems Travis-CI is misbehaving. Oh ok. It's fine in that case. Today, I didn't see this issue anymore :-) I was usually able to merge in

Re: [python-committers] Feedback on the new CPython workflow

2017-05-18 9:01 GMT-07:00 Mariatta Wijaya : > The question is: since backport branch is temporary and gets deleted once PR > is created, is this even important? I stopped using cherry-picker.py to use a simple shell script for the last step, create a PR from a local

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

2017-05-23 16:42 GMT-05:00 Senthil Kumaran : > Also, liked reading Victor's email. :) Thank you. It's my feedback of constructive discussions about the Python community at Pycon. Victor ___ python-committers mailing list

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

Le 24 mai 2017 17:17, "Guido van Rossum" a écrit : OK, I think we have enough +1 votes... Brett, will you make it happen? Well, that vote is just a world record in term of +1 in a short period of time! (I also count +1 for Guido if I understood correctly ;-)) Victor

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

Welcome Carol! Victor Le 24 mai 2017 7:41 PM, "Brett Cannon" a écrit : > Done! > > Carol, just accept the invitation to join the Python core team on GitHub > at https://github.com/python and that's it! (I already subscribed you to > python-committers under your Gmail account

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

Hi, I discussed with Mariatta and Carol at Pycon US about new contributors and the difficulty to find "easy issues" to start contributing to CPython. The thing is that easy issues usually are fixed in less than 24 hours which doesn't give the opportunity to newcomers to fix them. *Many* people

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

2017-06-15 5:31 GMT+02:00 Nick Coghlan : > I'm not necessarily opposed to such a policy change, but if folks > really want guaranteed green post-merge buildbots for all platforms > (rather than just guaranteed green for Linux & Windows, sometimes red > for everything else),

Re: [python-committers] IMPORTANT: Python 3.6.2 Maintenance Release Release Candidate in 3+ days (Monday 2017-06-12 12:00 UTC)

Oh, about very annoying 3.6 bug, there was a regression caused by FASTCALL optimizations. It's now fixed in the 3.6 branch: https://github.com/python/cpython/commit/f0ff849adc6b4a01f9d1f08d9ad0f1511ff84541 Victor 2017-06-09 5:34 GMT+02:00 Ned Deily : > We are approaching the

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

2017-06-14 18:38 GMT+02:00 Serhiy Storchaka : >> What do you think? Would you be ok with such rule? > > I think we first should make buildbots notifying the author of a > commit that broke tests or building, so his can either quickly fix the > failure or revert his commit.

Re: [python-committers] Promote Julien Palards as Committers on docsbuild-scripts

Le 14 juin 2017 00:29, "Brett Cannon" a écrit : It is, but the infrastructure team owns that repo, not Python core. -Brett Oh, I didn't know. Is it possible to see who owns a GitHub Python project at https://github.com/python/? If not, do you think that it would be worth it

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

Hi, The CPython workflow was enhanced to get pre-commit CI checks. That's a huge win, thank you for that... But, sometimes, a change can still break many buildbots, bugs which weren't catched by pre-commit checks (Travis CI/Linux and AppVeyor/Windows). Buildbots cover much more different

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

2017-06-14 18:38 GMT+02:00 Serhiy Storchaka : > I think we first should make buildbots notifying the author of a > commit that broke tests or building, so his can either quickly fix the > failure or revert his commit. Hum, I think that I should elaborate my previous email.

Re: [python-committers] Promote Julien Palards as Committers on docsbuild-scripts

2017-06-14 22:40 GMT+02:00 Brett Cannon : >> Oh, I didn't know. Is it possible to see who owns a GitHub Python project >> at https://github.com/python/? > > If you can see https://github.com/orgs/python/teams/python-core/repositories > then yes. :) About this list, there was a

Re: [python-committers] Promote Julien Palards as Committers on docsbuild-scripts

Oh nice, thanks to your change, it's now listed in the list! https://github.com/orgs/python/teams/python-core/repositories Victor 2017-06-15 22:40 GMT+02:00 Brett Cannon <br...@python.org>: > I've made Python core able to read the buildmaster-config repo. > > On Wed, 14 Jun 2017

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

2017-06-16 10:37 GMT+02:00 Nick Coghlan : > Hopefully reversions will continue to be rare (since relatively few > changes are likely to be as platform dependent as PEP 538, and > Windows/*nix differences are already covered in pre-merge CI), but > when they do come up, the

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

Hi Antoine, Buildbots got a new coloor last month: orange. It means that we detected "warnings", one of these warnings are tests which failed once but then passed when run a second time. I started to open an issue for each CI failure and for each unstable test (fail then pass). For

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

typo: 2017-06-13 8:42 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > See also *my* "buildbot report" emails to python-dev. Oh, it seems like you bug you saw is not in the bug tracker. I opened this issue: http://bugs.python.org/issue30643 You can use it to

[python-committers] Promote Julien Palards as Committers on docsbuild-scripts

Hi, Would it be possible to give the commit bit to Julien Palards on the following project (only on this project)? https://github.com/python/docsbuild-scripts/pulls His GitHub account is "JulienPalard": https://github.com/JulienPalard Thanks to the migration to GitHub, we are now able to

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

2017-05-02 23:37 GMT+02:00 Donald Stufft : > I think the only reason we don’t have them on is because the macOS builds on > Travis are _Super_ slow and regularly get a large backlog. Fast Finish and > Allowed Failures would help with that though. Maybe we can start with a small

Re: [python-committers] Coverage build broken?

2017-05-04 22:51 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > It seems like a real bug and a regression, I opened an issue to track it: > http://bugs.python.org/issue30273 Ok, it should be fixed by my commit: https://github.com/python/cp

Re: [python-committers] Coverage build broken?

2017-05-04 23:56 GMT+02:00 Brett Cannon : > Thanks, Victor! Well, I was also responsible of the breakage :-) But maybe it wasn't a good idea in the first place to use AST_H_DIR in distutils/sysconfig.py to get the "Include" string? ;-) Or maybe I missed a feature: is it

Re: [python-committers] Coverage build broken?

It seems like a real bug and a regression, I opened an issue to track it: http://bugs.python.org/issue30273 Victor 2017-05-04 16:44 GMT+02:00 Antoine Pitrou : > > Hello, > > I'm getting the following error on the Travis-CI coverage job: > (from

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

Le 20 sept. 2017 00:03, "Barry Warsaw" a écrit : I forget though, was it a problem with macOS CI stability or general throughput? I thought they just couldn’t keep up with the workload, in which case it seems like we should be able to throw more resources at it, right? There

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

months.) Victor 2017-09-06 1:30 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > Hi, > > I was bitten again by the issue on https://github.com/python/cpython/pull/3350 > > After restarting the Travis CI build twice (first by me, then by > Zach), I was able to merge it.

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

Ok. I closed https://bugs.python.org/issue31355 Victor 2017-09-23 22:58 GMT+02:00 Antoine Pitrou <anto...@python.org>: > > For the record: > https://blog.travis-ci.com/2017-09-22-macos-update > > Regards > > Antoine. > > > Le 01/09/2017 à 19:15, Victor Stinne

[python-committers] Should I merge a PR that I approved if it was written by a different core developer?

Git era, the author and committer *can* be two different people. Examples with "git log --pretty=full": commit 9abee722d448c1c00c7d4e11ce242ec7b13e5c49 Author: Victor Stinner <victor.stin...@gmail.com> Commit: GitHub <nore...@github.com> commit 8f51bb436f8adfd139cad046b91cd462c7f

Re: [python-committers] Should I merge a PR that I approved if it was written by a different core developer?

> I think it's a good idea in many cases, but not required. I'm not sure that I understood correctly, what is a good idea? To merge the PR if I consider that it's now good enough to be merged? > E.g. you may be OK > with the diff but still ask the author to clean up some small nits, and then >

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

Hi, Recently, I asked their opinion to a few core developers about promoting some active contributors to core developers. It seems like we have no clear rules to decide if a contributor can be promoted or not. The problem is that sometimes, I am explicitly asked: What are the steps to become a

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

2017-09-22 18:48 GMT+02:00 Antoine Pitrou : >> * Long term commitement. (...) > > Unfortunately we can't evaluate that in advance. Even the person being > promoted often does not known whether they'll still be there in 5 or 10 > years. Hopefully that's on their horizon, but

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

2017-09-24 13:05 GMT+02:00 Nick Coghlan : > I think what we put there really does cover the essence of the role, > so the main questions I personally ask about a potential new core > developer are: > > 1. Would gaining core developer privileges improve their ability to >

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

the macOS job: https://bugs.python.org/issue31355 Please read the issue for the full rationale. Victor 2017-09-01 19:15 GMT+02:00 Victor Stinner <victor.stin...@gmail.com>: > Hi, > > Since today, it seems like the macOS task of a Travis CI job to > validate a pull request h

Re: [python-committers] Hacktoberfest

Hi, 2017-09-28 18:21 GMT+02:00 Mariatta Wijaya : > October is hacktoberfest (https://hacktoberfest.digitalocean.com/) > In the month of October, people can sign up and contribute to open source > projects on GitHub. If they make 4 PRs during Hacktoberfest, they'll earn

Re: [python-committers] Travis CI build on python/cpython passes in error

The Travis CI config runs the command: git diff --name-only 49f6449ef4b81537c19b82329caaf60596c516c2...d0c822cded495409b68432fa10f9573417ca1fb7 Git fails with "fatal: Invalid symmetric difference expression (...)" if it doesn't know one or both sha1. The first problem is that

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

Hi, Since today, it seems like the macOS task of a Travis CI job to validate a pull request hangs the whole job. Don't try to cancel the macOS job, or the whole job will be marked as failed! ... even if macOS is in the "Allowed Failure" section. I don't know the best way to "repair" such job. I

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

Le 1 sept. 2017 7:24 PM, "Antoine Pitrou" <anto...@python.org> a écrit : Le 01/09/2017 à 19:15, Victor Stinner a écrit : > > Yesterday, it was possible to merge a PR even if the macOS job was > still queued (no started). It's still possible today. Ah? The merge bu

<    1   2   3   4   5   >