From nad at python.org Mon Jul 3 00:43:06 2017 From: nad at python.org (Ned Deily) Date: Mon, 3 Jul 2017 00:43:06 -0400 Subject: [python-committers] 3.6.2 update: 3.6.2rc2 coming Message-ID: As you may recall, 3.6.2rc1 was released on 2017-06-17 with an expected release date of 3017-06-30 for 3.6.2 final. As you also may recall, 3.6.2rc1 was delayed a bit to address some security issues including updating our version of libexpat. Shortly after 3.6.2rc1 was released, the expat project released another version of libexpat fixing another security problem. Also since 3.6.2rc1, fixes for several other security issues in Python 3.6 itself have become available and it would be better to get them out sooner rather than later. Therefore, I have decided to do a second release candidate with select fixes cherry-picked from the 3.6 branch; continue to merge bug fixes and doc fixes into 3.6 as usual for release in 3.6.3. Since there haven't been regressions reported so far with 3.6.2rc1, we will plan to compress the rest of the release cycle. 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). --Ned -- Ned Deily nad at python.org -- [] From victor.stinner at gmail.com Wed Jul 5 09:51:01 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 5 Jul 2017 15:51:01 +0200 Subject: [python-committers] Revert changes which break too many buildbots In-Reply-To: References: Message-ID: Ok, since I spent weeks on fixing buildbots, I'm now more confident that our buildbots are super stable. Since a test_datetime change introduced a *regression* (ARMv7 started to fail), I reverted the first commit: https://github.com/python/cpython/pull/2588 Again, it's not to reject the change, just to repair the buildbot to get more time to design and test the proper fix. Because of a bug, test_datetime only tested the C implementation of datetime. The change enables tests on Lib/datetime.py, the Python implementation. Suddenly, test_datetime started to take up to 20 minutes to run! 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 : > 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 architectures and platforms. > > I spend a significant amount of time to maintain the sanity of our > buildbots. Sometimes, it can take me up to 3 days on a week (of 5 > working days). It's annoying to see new regressions while I'm trying > hard to fix old ones :-( > > So I would like to set a new rule: if I'm unable to fix buildbots > failures caused by a recent change quickly (say, in less than 2 > hours), I propose to revert the change. > > It doesn't mean that the commit is bad and must not be merged ever. > No. It would just mean that we need time to work on fixing the issue, > and it shouldn't impact other pending changes, to keep a sane master > branch. > > What do you think? Would you be ok with such rule? > > A recent example is Nick Coghlan's implementation of the PEP 538: > basically, it broke all buildbots... except of Linux and Windows :-) > And it will take a few more days to fix all failures. Well, we are > working on fixing these issues, so I don't want to revert this change. > It's just an example of a single change which broke many buildbots. > The PEP 538 depends a lot on the platform, so I'm not surprised to see > different failures per platforms ;-) > > By "buildbot failure", I mean a red buildbot failing because of > compilation error or failed test suite. But I would prefer to ignore > failures of the Refleak buildbots since these ones are not stable > (even if there are less and less ref leaks in master, and these > buildbots already catched recent regressions!). > > If the rule is approved, I plan to announce it on python-dev to be transparent. > > Victor From victor.stinner at gmail.com Wed Jul 5 10:03:05 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 5 Jul 2017 16:03:05 +0200 Subject: [python-committers] Revert changes which break too many buildbots In-Reply-To: References: Message-ID: 2017-07-05 15:51 GMT+02:00 Victor Stinner : > Ok, since I spent weeks on fixing buildbots, I'm now more confident > that our buildbots are super stable. Since a test_datetime change > introduced a *regression* (ARMv7 started to fail), I reverted the > first commit: > https://github.com/python/cpython/pull/2588 Crap. I created this PR using the [Revert] button. While the changes are fine, I didn't notice the giant commit message which is wrong and spamed me with notifications on unrelated issues :-/ Sorry for the spam... commit 8207c17486baece8ed0ac42d9f8d69ecec4ba7e4 Author: Victor Stinner Date: Wed Jul 5 15:44:52 2017 +0200 Revert "bpo-30822: Fix testing of datetime module." (#2588) * Revert "bpo-30854: Fix compile error when --without-threads (#2581)" This reverts commit 0c3116309307ad2c7f8e2d2096612f4ab33cbb62. * Revert "NEWS for 30777 (#2576)" This reverts commit aaa917ff38f9869eeebe3bc9469bfee64089d826. * Revert "bpo-21624: IDLE -- minor htest fixes (#2575)" This reverts commit 2000150c569941584994ec4ec59171961209bec3. * Revert "bpo-30777: IDLE: configdialog - add docstrings and improve comments (#2440)" This reverts commit 7eb5883ac59833bf63f0e1f7fb95671a1ac1ee08. * Revert "bpo-30319: socket.close() now ignores ECONNRESET (#2565)" This reverts commit 67e1478dba6efe60b8e1890192014b8b06dd6bd9. * Revert "bpo-30789: Use a single memory block for co_extra. (#2555)" This reverts commit 378ebb6578b9d709f38b888d23874c0b18125249. * Revert "bpo-30845: Enhance test_concurrent_futures cleanup (#2564)" This reverts commit 3df9dec425b0254df1cdf41922fd8d6b08bf47e4. * Revert "bpo-29293: multiprocessing.Condition.notify() lacks parameter `n` (#2480)" This reverts commit 48350412b70c76fa51f488cfc736c80d59b5e8eb. * Revert "Remove outdated FOX from GUI FAQ (GH-2538)" This reverts commit d3ed2877a798d07df75422afe136b4727e500c99. * Revert "bpo-6691: Pyclbr now reports nested classes and functions. (#2503)" This reverts commit 246ff3bd00f97658e567a7087645a6b76e056491. * Revert "bpo-29464: Rename METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and make (#1955)" This reverts commit 6969eaf4682beb01bc95eeb14f5ce6c01312e297. * Revert "bpo-30832: Remove own implementation for thread-local storage (#2537)" This reverts commit aa0aa0492c5fffe750a26d2ab13737a1a6d7d63c. * Revert "bpo-30764: Fix regrtest --fail-env-changed --forever (#2536)" This reverts commit 5e87592fd12e0b7c41edc11d4885ed7298d5063b. * Revert "bpo-30822: Deduplicate ZoneInfoTest classes in test_datetime. (#2534)" This reverts commit 34b54873b51a1ebee2a3c57b7205537b4f33128d. * Revert "bpo-30822: Fix testing of datetime module. (#2530)" This reverts commit 98b6bc3bf72532b784a1c1fa76eaa6026a663e44. Victor From tjreedy at udel.edu Wed Jul 5 16:26:18 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 5 Jul 2017 16:26:18 -0400 Subject: [python-committers] Revert changes which break too many buildbots In-Reply-To: References: Message-ID: <16002525-ff95-1c9a-c03b-38b6da6e2c3d@udel.edu> On 7/5/2017 10:03 AM, Victor Stinner wrote: > 2017-07-05 15:51 GMT+02:00 Victor Stinner : >> Ok, since I spent weeks on fixing buildbots, I'm now more confident >> that our buildbots are super stable. Since a test_datetime change >> introduced a *regression* (ARMv7 started to fail), I reverted the >> first commit: >> https://github.com/python/cpython/pull/2588 > > Crap. I created this PR using the [Revert] button. While the changes > are fine, I didn't notice the giant commit message which is wrong and > spamed me with notifications on unrelated issues :-/ Committers should always review checkin messages. Unless a PR is made with a single commit, the message usually needs editing. > Sorry for the spam... Each tracker issue mentioned below got a bogus reversion message. But better the spam than an actual reversion ;-). I unlinked the ones for IDLE. You should go through the rest. Terry From victor.stinner at gmail.com Thu Jul 6 04:52:47 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Thu, 6 Jul 2017 10:52:47 +0200 Subject: [python-committers] [Python-Dev] 3.6.2 update: 3.6.2rc2 coming In-Reply-To: References: Message-ID: 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 https://docs.python.org/3.6/whatsnew/changelog.html will get items from Misc/NEWS.d/ ;-) Victor From nad at python.org Sat Jul 8 01:22:32 2017 From: nad at python.org (Ned Deily) Date: Sat, 8 Jul 2017 01:22:32 -0400 Subject: [python-committers] [RELEASE] Python 3.6.2rc2 is now available for testing Message-ID: <4B22E08B-9C6C-47F6-B908-CC7676D43B77@python.org> On behalf of the Python development community and the Python 3.6 release team, I would like to announce the availability of Python 3.6.2rc2. 3.6.2rc2 is the second release candidate for Python 3.6.2, the next maintenance release of Python 3.6. 3.6.2rc2 includes fixes for three security-related issues resolved since the previous release candidate; see the change log (link below). While 3.6.2rc2 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). Please see "What?s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.2rc2 here: https://www.python.org/downloads/release/python-362rc2/ and its change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-2-release-candidate-2 3.6.2 is now planned for final release on 2017-07-17 with the next maintenance release expected to follow in about 3 months. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad at python.org -- [] From storchaka at gmail.com Mon Jul 10 09:14:11 2017 From: storchaka at gmail.com (Serhiy Storchaka) Date: Mon, 10 Jul 2017 16:14:11 +0300 Subject: [python-committers] Please edit the commit message when merge a PR Message-ID: When a PR is consistent on several commits, the final commit message composed by GitHub contains messages of all these commits: "fix typo", "address yyy comments", "revert zzz". If the initial commit message contained errors (e.g. absent issue number), it is easy to edit the title and text of a PR, but the initial commit message lefts unchanged. GitHub allows to edit the commit message of squashed commit, and please don't ignore this possibility. Otherwise the commit message in the repository will be ugly if not worse. From berker.peksag at gmail.com Mon Jul 10 10:49:04 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Mon, 10 Jul 2017 17:49:04 +0300 Subject: [python-committers] Please edit the commit message when merge a PR In-Reply-To: References: Message-ID: On Mon, Jul 10, 2017 at 4:14 PM, Serhiy Storchaka wrote: > When a PR is consistent on several commits, the final commit message > composed by GitHub contains messages of all these commits: "fix typo", > "address yyy comments", "revert zzz". If the initial commit message > contained errors (e.g. absent issue number), it is easy to edit the title > and text of a PR, but the initial commit message lefts unchanged. GitHub > allows to edit the commit message of squashed commit, and please don't > ignore this possibility. Otherwise the commit message in the repository will > be ugly if not worse. +1! (and thank you for writing this email, Serhiy) I can't think of a way to automatically prevent a PR from merging if body of the squashed commit contains "fix typo" commits. I think this is a pretty annoying problem and perhaps we should ask contributors to squash multiple commits themselves even if we continue to use the "squash and merge" option. From victor.stinner at gmail.com Mon Jul 10 10:57:43 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 10 Jul 2017 16:57:43 +0200 Subject: [python-committers] Please edit the commit message when merge a PR In-Reply-To: References: Message-ID: 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. GitHub PR UI is not ideal to review commit messages :-/ Victor 2017-07-10 15:14 GMT+02:00 Serhiy Storchaka : > When a PR is consistent on several commits, the final commit message > composed by GitHub contains messages of all these commits: "fix typo", > "address yyy comments", "revert zzz". If the initial commit message > contained errors (e.g. absent issue number), it is easy to edit the title > and text of a PR, but the initial commit message lefts unchanged. GitHub > allows to edit the commit message of squashed commit, and please don't > ignore this possibility. Otherwise the commit message in the repository will > be ugly if not worse. > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From barry at python.org Mon Jul 10 11:09:37 2017 From: barry at python.org (Barry Warsaw) Date: Mon, 10 Jul 2017 11:09:37 -0400 Subject: [python-committers] Please edit the commit message when merge a PR In-Reply-To: References: Message-ID: <20170710110937.19703e85@presto.wooz.org> On Jul 10, 2017, at 04:57 PM, Victor Stinner wrote: >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. > >GitHub PR UI is not ideal to review commit messages :-/ GitLab is roughly the same, and I always edit commit messages when squash merging. While ideally the author could do this, I think sensible commit messages are more important, so +1 for having the committer edit them at their discretion. -Barry From guido at python.org Mon Jul 10 11:35:07 2017 From: guido at python.org (Guido van Rossum) Date: Mon, 10 Jul 2017 08:35:07 -0700 Subject: [python-committers] Please edit the commit message when merge a PR In-Reply-To: <20170710110937.19703e85@presto.wooz.org> References: <20170710110937.19703e85@presto.wooz.org> Message-ID: 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 the review). So I'm with Sergey. This is how we do it in the mypy-related projects. On Mon, Jul 10, 2017 at 8:09 AM, Barry Warsaw wrote: > On Jul 10, 2017, at 04:57 PM, Victor Stinner wrote: > > >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. > > > >GitHub PR UI is not ideal to review commit messages :-/ > > GitLab is roughly the same, and I always edit commit messages when squash > merging. While ideally the author could do this, I think sensible commit > messages are more important, so +1 for having the committer edit them at > their > discretion. > > -Barry > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Mon Jul 10 22:21:45 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 10 Jul 2017 22:21:45 -0400 Subject: [python-committers] Please edit the commit message when merge a PR In-Reply-To: References: Message-ID: <4b79380d-1f7e-c669-f944-c3f1992e6765@udel.edu> On 7/10/2017 10:49 AM, Berker Peksa? wrote: > On Mon, Jul 10, 2017 at 4:14 PM, Serhiy Storchaka wrote: >> When a PR is consistent on several commits, the final commit message >> composed by GitHub contains messages of all these commits: "fix typo", >> "address yyy comments", "revert zzz". If the initial commit message >> contained errors (e.g. absent issue number), it is easy to edit the title >> and text of a PR, but the initial commit message lefts unchanged. GitHub >> allows to edit the commit message of squashed commit, and please don't >> ignore this possibility. Otherwise the commit message in the repository will >> be ugly if not worse. > > +1! (and thank you for writing this email, Serhiy) Ditto. > I can't think of a way to automatically prevent a PR from merging if > body of the squashed commit contains "fix typo" commits. I think this > is a pretty annoying problem and perhaps we should ask contributors to > squash multiple commits themselves even if we continue to use the > "squash and merge" option. When people did that, we asked them not to. When reviewing, I want to be able to see both commits in response to comments and the total diff (by clicking files at the top). If people push a squash merge after a PR is approved both by CI and core reviewer, they might make a mistake. In any case, another round of CI is triggered. In any case, I find editing easy. I often delete all and copy from the new blurb. When I write a patch myself, I try to write at least some commit messages that should remain in the final result. So I might copy some commit messages into the blurb. From victor.stinner at gmail.com Tue Jul 11 04:14:42 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 11 Jul 2017 10:14:42 +0200 Subject: [python-committers] Please edit the commit message when merge a PR In-Reply-To: References: <20170710110937.19703e85@presto.wooz.org> Message-ID: 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 the review). So I'm with Sergey. This is how we do it in the > mypy-related projects. Oh, I noticed that comments were hidden after a rebase or squash. But I never understood the link between squash/rebase and hidden comments. Ok, it makes sense to prefer merge and multiple commits to workaround UI limitations of GitHub PRs :-) Victor From brett at python.org Tue Jul 11 12:39:46 2017 From: brett at python.org (Brett Cannon) Date: Tue, 11 Jul 2017 16:39:46 +0000 Subject: [python-committers] Please edit the commit message when merge a PR In-Reply-To: References: Message-ID: On Mon, 10 Jul 2017 at 07:57 Berker Peksa? wrote: > On Mon, Jul 10, 2017 at 4:14 PM, Serhiy Storchaka > wrote: > > When a PR is consistent on several commits, the final commit message > > composed by GitHub contains messages of all these commits: "fix typo", > > "address yyy comments", "revert zzz". If the initial commit message > > contained errors (e.g. absent issue number), it is easy to edit the title > > and text of a PR, but the initial commit message lefts unchanged. GitHub > > allows to edit the commit message of squashed commit, and please don't > > ignore this possibility. Otherwise the commit message in the repository > will > > be ugly if not worse. > > +1! (and thank you for writing this email, Serhiy) > > I can't think of a way to automatically prevent a PR from merging if > body of the squashed commit contains "fix typo" commits. I think this > is a pretty annoying problem and perhaps we should ask contributors to > squash multiple commits themselves even if we continue to use the > "squash and merge" option. > There's isn't a way to block a merge at that stage. But one thing I've been thinking about is adding a check to Bedevere post-merge that sees if the commit message was left unchanged (not quite sure if I can come up with a reliable heuristic, though). In instances where the committers forgot, Bedevere would simply leave a message saying something like, "Hey, thanks for taking the time to merge a PR, but please don't forget to clean up the commit message before merging." Basically a friendly reminder to not forget next time (I'm also thinking of doing something similar for the formatting of the PR title after merging). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Tue Jul 11 17:20:52 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Tue, 11 Jul 2017 23:20:52 +0200 Subject: [python-committers] Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California In-Reply-To: References: Message-ID: Hi, I signed up but haven't heard any news yet. September is approaching, so it would be great to know if you are still deciding/negotiating or if you already know the names :) Best Regards, Ezio Melotti On Tue, Jun 13, 2017 at 1:04 AM, Lukasz Langa wrote: > Hello fellow committers! > I'm organizing another core sprint this year to make Python 3.7 the best > release possible. > > *WHY*: > 1. *Community*. The sprints at the end of PyCon are great but they > mostly get the same people in the room year after year. Many of the most > active contributors never attend conferences. My goal with this sprint is > to bring together many core devs who rarely if ever meet! > 2. *Focus*. When we have sprints at the end of a conference, many of us > are pretty tired and less productive than we could have been without the > late dinners, endless hallway sessions, and so on. Some of the sprinters > are preoccupied with tutoring newcomers. This sprint won't be after a > major conference, and it's only for seasoned CPython core devs--so get to > work! > 3. *Communication*. There are tremendous benefits to getting everyone > together in one big room. Conversations that drag on on python-dev can be > solved quickly in person. Even contentious debates become faster, easier, > and more civil. And meeting face-to-face helps us all feel more connected > to our community. > > *WHY THE BAY AREA*: We have a large population of core contributors > here. Also, I can arrange for Facebook to provide us a "war room" for the > whole week, with full access to the campus during the sprints. That > includes free food for breakfast, lunch, dinner, and snacks, compatible > with almost any dietary restrictions. > > *WHY EARLY SEPTEMBER*: It's almost impossible to find a time that doesn't > overlap with a PyCon. This week worked well last year so we're redoing it > that way. Monday September 4 is Labor Day in the US, which may make it > easier for employees of US companies to attend, as they'd only be taking > off four days instead of five. > > *HOW LONG*: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can > check into your hotel the day before the sprint (Sunday, Sep 3) and check > out the day after (Saturday, Sep 9). > > *HOW BIG*: No fewer than 10, no more than 20. More than 20 people would > be great but it'd be hard for me to organize a sprint that big. > > *WHO PAYS*: The venue, hotels, and food are provided by Facebook. I'm > working on getting flight reimbursements. Last year they were provided by > the Python Software Foundation. Anybody is free to waive their > reimbursement. > > *PLEASE REPLY*: If you're interested in attending and have the commit bit > on GitHub's python/cpython, fill out this Google Form: > https://goo.gl/forms/MzrNtRe0NAmzvGwF2 > > *DISCLAIMER*: I'd like to be able to host everybody. However, if I > receive more than 20 applications, this is not going to be possible. In > this case, the following will happen: > > 1. I will look at your current level of involvement in CPython > development. This includes metrics like commits / PRs, activity on the bug > tracker and python-dev, special role (release manager, infrastructure dev, > etc.). > 2. I will look at your sprint plan and ability to participate in the > entire sprint (per answers to the questions above). > 3. I will gather all this data and leave the final decision to our > Benevolent Dictator (who is also attending the sprint). This is one of > those occasions where having a dictator is useful. > > *DON'T WAIT*: September is closer than you think! Please let me know as > soon as possible so we can start setting up the event. I'm going to close > the sign-up form on June 23rd. > > Organizational-ly yours, > ? > Vice-Minister of Silly Sprints > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at langa.pl Wed Jul 12 07:55:14 2017 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 12 Jul 2017 13:55:14 +0200 Subject: [python-committers] UPDATE 1: Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California In-Reply-To: References: Message-ID: <216145AA-1D2B-401A-867A-DCF354494038@langa.pl> Update: the sprint is on! Good news: Facebook is covering the venue, food and hotel costs. This is confirmed. I'm working on getting a PSF grant for flights like last year. Please book your airplane tickets as soon as possible. Like last year, we can reimburse up to $500 for domestic roundtrip flights and up to $1500 for international roundtrip flights. If that?s not enough to get you to California and back, let me know and we?ll figure something out. Send me the receipts my way, you should get your money back before the event, preferably as soon as I get the grant wired. For sums smaller than $500, provide me with a PayPal e-mail. For larger ones, I will need your details to set up a wire transfer. I will use TransferWise for the latter to cut down the wire costs. I recommend flying in on Sunday and flying out on Saturday. Please DO NOT book hotels, Facebook is covering this, preferably in the same hotel as close to Facebook HQ as possible. NOTE: I cannot confirm your hotel room until I have your flight information. Full list of confirmed attendance: zware ned-deily ncoghlan warsaw benjaminp tiran ericvsmith 1st1 larryhastings ericsnowcurrently Mariatta ezio-melotti applio nascheme bitdancer gvanrossum gpshead zooba haypo rhettinger If for any reason you can no longer come, please let me know immediately. - ? > On Jun 13, 2017, at 1:04 AM, Lukasz Langa wrote: > > Hello fellow committers! > I'm organizing another core sprint this year to make Python 3.7 the best release possible. > > WHY: > 1. Community. The sprints at the end of PyCon are great but they mostly get the same people in the room year after year. Many of the most active contributors never attend conferences. My goal with this sprint is to bring together many core devs who rarely if ever meet! > 2. Focus. When we have sprints at the end of a conference, many of us are pretty tired and less productive than we could have been without the late dinners, endless hallway sessions, and so on. Some of the sprinters are preoccupied with tutoring newcomers. This sprint won't be after a major conference, and it's only for seasoned CPython core devs--so get to work! > 3. Communication. There are tremendous benefits to getting everyone together in one big room. Conversations that drag on on python-dev can be solved quickly in person. Even contentious debates become faster, easier, and more civil. And meeting face-to-face helps us all feel more connected to our community. > > WHY THE BAY AREA: We have a large population of core contributors here. Also, I can arrange for Facebook to provide us a "war room" for the whole week, with full access to the campus during the sprints. That includes free food for breakfast, lunch, dinner, and snacks, compatible with almost any dietary restrictions. > > WHY EARLY SEPTEMBER: It's almost impossible to find a time that doesn't overlap with a PyCon. This week worked well last year so we're redoing it that way. Monday September 4 is Labor Day in the US, which may make it easier for employees of US companies to attend, as they'd only be taking off four days instead of five. > > HOW LONG: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can check into your hotel the day before the sprint (Sunday, Sep 3) and check out the day after (Saturday, Sep 9). > > HOW BIG: No fewer than 10, no more than 20. More than 20 people would be great but it'd be hard for me to organize a sprint that big. > > WHO PAYS: The venue, hotels, and food are provided by Facebook. I'm working on getting flight reimbursements. Last year they were provided by the Python Software Foundation. Anybody is free to waive their reimbursement. > > PLEASE REPLY: If you're interested in attending and have the commit bit on GitHub's python/cpython, fill out this Google Form: > https://goo.gl/forms/MzrNtRe0NAmzvGwF2 > > DISCLAIMER: I'd like to be able to host everybody. However, if I receive more than 20 applications, this is not going to be possible. In this case, the following will happen: > > 1. I will look at your current level of involvement in CPython development. This includes metrics like commits / PRs, activity on the bug tracker and python-dev, special role (release manager, infrastructure dev, etc.). > 2. I will look at your sprint plan and ability to participate in the entire sprint (per answers to the questions above). > 3. I will gather all this data and leave the final decision to our Benevolent Dictator (who is also attending the sprint). This is one of those occasions where having a dictator is useful. > > DON'T WAIT: September is closer than you think! Please let me know as soon as possible so we can start setting up the event. I'm going to close the sign-up form on June 23rd. > > Organizational-ly yours, > ? > Vice-Minister of Silly Sprints > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From larry at hastings.org Wed Jul 12 09:09:50 2017 From: larry at hastings.org (Larry Hastings) Date: Wed, 12 Jul 2017 15:09:50 +0200 Subject: [python-committers] Should I make a 3.4.7rc1 next weekend? Message-ID: <20ec439d-5735-1285-5380-ae22b57c50c6@hastings.org> I'm scheduled to tag and release 3.5.4rc1 next weekend. I've been releasing 3.4 and 3.5 at the same time for the last year; this is convenient for me as it halves the frequency with which I have to put on the "release manager" hat. There are currently no scheduled dates to release 3.4.7. The reason being that until very recently there was almost no work done in 3.4 since 3.4.6 was tagged. But! The reason for /that/ was because of a change in the workflow: once we switched to Github, for branches that are in security-fixes-only mode, only the Release Manager is allowed to accept PRs into that branch. It turned out there were a bunch of PRs waiting for my approval. After a flurry of accepted PRs, I have now accrued about ten fresh security fixes in the 3.4 branch. (Mostly from Victor, but also Serhiy, and one from Barry--thanks everyone!) There are now no outstanding security fix PRs against 3.4. Since I'm releasing 3.5.4rc1 next weekend, I wouldn't mind /also/ releasing 3.47rc1 next weekend. That would put 3.4.7 final the same day as 3.5.4 final: just over three weeks from now, releasing on Sunday August 5. I realize it's not much notice, and that's normally not how we do things in the CPython world. (Sorry for the short notice--it's my fault for not adjusting to the new workflow quickly enough.) Anyway the point of this email is to call for a vote. Which of these statements do you agree with: * Larry should tag and release 3.4.7rc1 next weekend. * Larry should schedule 3.4.7rc1 for a month from now, to give people time to get their work in. In particular, Victor and Serhiy, I'm interested in your votes. You both get veto powers for the short notice--if either of you say "do it a month from now" then it'll be a month from now. Also, if anybody has security fixes you want to get in to the next release of 3.4, but you haven't made a PR yet, please reply and describe them. (Please reply to list if appropriate, but if it should be kept quiet please reply to me directly.) Braising in my own juices at EuroPython, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Wed Jul 12 09:12:50 2017 From: larry at hastings.org (Larry Hastings) Date: Wed, 12 Jul 2017 15:12:50 +0200 Subject: [python-committers] Reminder: 3.5.4rc1 will be tagged next Saturday, July 22 2017 Message-ID: Just a quick reminder. I'll be tagging 3.5.4rc1 next Saturday, July 22. 3.5.4 final will be the last release of 3.5.4 that accepts bugfixes; after that, the 3.5 branch will transition to security-fixes-only mode. If you have bugfixes you want to ship with 3.5.4, please get them committed in the next nine days. Happy hacking, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Wed Jul 12 09:18:42 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 12 Jul 2017 15:18:42 +0200 Subject: [python-committers] Should I make a 3.4.7rc1 next weekend? In-Reply-To: <20ec439d-5735-1285-5380-ae22b57c50c6@hastings.org> References: <20ec439d-5735-1285-5380-ae22b57c50c6@hastings.org> Message-ID: I would love to have a new 3.4 release including all security fixes, sure! It would reduce the number of known vulnerability in Python 3.4: http://python-security.readthedocs.io/vulnerabilities.html 2017-07-12 15:09 GMT+02:00 Larry Hastings : > After a flurry of accepted PRs, I have now accrued about ten fresh security > fixes in the 3.4 branch. (Mostly from Victor, but also Serhiy, and one from > Barry--thanks everyone!) There are now no outstanding security fix PRs > against 3.4. Thanks for merging them ;-) I would like to see my "[3.4] Backport CI config from master" PR merged into 3.4 to get at least a check from Travis and AppVeyor that there is no major regression on Linux and Windows: https://github.com/python/cpython/pull/2475 If I recall correctly, it would be the first time that we have a CI for a branch in security-fix only mode, no? Victor From storchaka at gmail.com Wed Jul 12 12:02:39 2017 From: storchaka at gmail.com (Serhiy Storchaka) Date: Wed, 12 Jul 2017 19:02:39 +0300 Subject: [python-committers] Should I make a 3.4.7rc1 next weekend? In-Reply-To: <20ec439d-5735-1285-5380-ae22b57c50c6@hastings.org> References: <20ec439d-5735-1285-5380-ae22b57c50c6@hastings.org> Message-ID: 12.07.17 16:09, Larry Hastings ????: > Anyway the point of this email is to call for a vote. Which of these > statements do you agree with: > > * Larry should tag and release 3.4.7rc1 next weekend. > * Larry should schedule 3.4.7rc1 for a month from now, to give people > time to get their work in. I'm for releasing 3.4.7rc1 next weekend. There were not much security issues and seems all worth fixes already are backported and merged in 3.4 (thank you for merging them). The rest of the work can be done in few days. I have just one suggestion. Issue26617 and issue28427 were not marked as security issues but they look like very bad bugs to me. They are hard to catch, can unexpectedly break any program that uses weakref and threads, and don't have workarounds. If you will decide to backport them I can help with backporting. https://bugs.python.org/issue26617 https://bugs.python.org/issue28427 From ezio.melotti at gmail.com Wed Jul 12 15:00:50 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Wed, 12 Jul 2017 21:00:50 +0200 Subject: [python-committers] UPDATE 1: Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California In-Reply-To: <216145AA-1D2B-401A-867A-DCF354494038@langa.pl> References: <216145AA-1D2B-401A-867A-DCF354494038@langa.pl> Message-ID: Hi, On Wed, Jul 12, 2017 at 1:55 PM, ?ukasz Langa wrote: > Update: the sprint is on! > > *Good news*: Facebook is covering the venue, food and hotel costs. This > is confirmed. I'm working on getting a PSF grant for flights like last year. > > Great news, and thanks for organizing the sprint! > *Please book your* *airplane tickets* as soon as possible. Like last > year, we can reimburse up to *$500* for domestic roundtrip flights and up > to *$1500* for international roundtrip flights. If that?s not enough to > get you to California and back, let me know and we?ll figure something out. > Send me the receipts my way, you should get your money back before the > event, preferably as soon as I get the grant wired. For sums smaller than > $500, provide me with a PayPal e-mail. For larger ones, I will need your > details to set up a wire transfer. I will use TransferWise for the latter > to cut down the wire costs. * I recommend flying in on Sunday and flying > out on Saturday.* > > Other than the cost, are there any restrictions on the flight? If possible I would like to spend some more time in the US after the sprint. By booking the return flight on a later date the total price of the flight should be similar if not cheaper. Of course I'll take care of the hotel and other expenses -- I don't want to take advantage of the PSF. If that is fine, I can contact you off-list and provide more information. Both the SFO and SJC airports seem to be close to Menlo Park. Is there any preference on the airport? Does the hotel provide any shuttle service? > *Please DO NOT book hotels*, Facebook is covering this, preferably in the > same hotel as close to Facebook HQ as possible. NOTE: I cannot confirm your > hotel room until I have your flight information. > > *Full list of confirmed attendance:* > zware > ned-deily > ncoghlan > warsaw > benjaminp > tiran > ericvsmith > 1st1 > larryhastings > ericsnowcurrently > Mariatta > ezio-melotti > applio > nascheme > bitdancer > gvanrossum > gpshead > zooba > haypo > rhettinger > > This is quite an impressive list, I'm looking forward meeting you all! Best Regards, Ezio Melotti > If for any reason you can no longer come, *please let me know immediately* > . > > - ? > > > > On Jun 13, 2017, at 1:04 AM, Lukasz Langa wrote: > > Hello fellow committers! > I'm organizing another core sprint this year to make Python 3.7 the best > release possible. > > *WHY*: > 1. *Community*. The sprints at the end of PyCon are great but they > mostly get the same people in the room year after year. Many of the most > active contributors never attend conferences. My goal with this sprint is > to bring together many core devs who rarely if ever meet! > 2. *Focus*. When we have sprints at the end of a conference, many of us > are pretty tired and less productive than we could have been without the > late dinners, endless hallway sessions, and so on. Some of the sprinters > are preoccupied with tutoring newcomers. This sprint won't be after a > major conference, and it's only for seasoned CPython core devs--so get to > work! > 3. *Communication*. There are tremendous benefits to getting everyone > together in one big room. Conversations that drag on on python-dev can be > solved quickly in person. Even contentious debates become faster, easier, > and more civil. And meeting face-to-face helps us all feel more connected > to our community. > > *WHY THE BAY AREA*: We have a large population of core contributors > here. Also, I can arrange for Facebook to provide us a "war room" for the > whole week, with full access to the campus during the sprints. That > includes free food for breakfast, lunch, dinner, and snacks, compatible > with almost any dietary restrictions. > > *WHY EARLY SEPTEMBER*: It's almost impossible to find a time that doesn't > overlap with a PyCon. This week worked well last year so we're redoing it > that way. Monday September 4 is Labor Day in the US, which may make it > easier for employees of US companies to attend, as they'd only be taking > off four days instead of five. > > *HOW LONG*: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can > check into your hotel the day before the sprint (Sunday, Sep 3) and check > out the day after (Saturday, Sep 9). > > *HOW BIG*: No fewer than 10, no more than 20. More than 20 people would > be great but it'd be hard for me to organize a sprint that big. > > *WHO PAYS*: The venue, hotels, and food are provided by Facebook. I'm > working on getting flight reimbursements. Last year they were provided by > the Python Software Foundation. Anybody is free to waive their > reimbursement. > > *PLEASE REPLY*: If you're interested in attending and have the commit bit > on GitHub's python/cpython, fill out this Google Form: > https://goo.gl/forms/MzrNtRe0NAmzvGwF2 > > *DISCLAIMER*: I'd like to be able to host everybody. However, if I > receive more than 20 applications, this is not going to be possible. In > this case, the following will happen: > > 1. I will look at your current level of involvement in CPython > development. This includes metrics like commits / PRs, activity on the bug > tracker and python-dev, special role (release manager, infrastructure dev, > etc.). > 2. I will look at your sprint plan and ability to participate in the > entire sprint (per answers to the questions above). > 3. I will gather all this data and leave the final decision to our > Benevolent Dictator (who is also attending the sprint). This is one of > those occasions where having a dictator is useful. > > *DON'T WAIT*: September is closer than you think! Please let me know as > soon as possible so we can start setting up the event. I'm going to close > the sign-up form on June 23rd. > > Organizational-ly yours, > ? > Vice-Minister of Silly Sprints > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Jul 14 14:33:23 2017 From: brett at python.org (Brett Cannon) Date: Fri, 14 Jul 2017 18:33:23 +0000 Subject: [python-committers] "trivial" label replaced with "skip issue" Message-ID: 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), the "trivial" label has been replaced with a "skip issue" label to signal that the issue number check should be skipped. The plan is that when we start having a status check for news entries there will be a "skip news" label to skip that status check. Dropping the all-inclusive "trivial" label helps keep us honest and only skip checks that are truly appropriate for a PR since these are skipping information-tracking things. I've also gone ahead and make the issue number check required on all branches since I think Bedevere has proven itself to be reliable enough to be a blocker and since we have the "skip" labels as an escape hatch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Sat Jul 15 08:26:10 2017 From: larry at hastings.org (Larry Hastings) Date: Sat, 15 Jul 2017 14:26:10 +0200 Subject: [python-committers] Announcing the schedule for 3.4.7 In-Reply-To: <20ec439d-5735-1285-5380-ae22b57c50c6@hastings.org> References: <20ec439d-5735-1285-5380-ae22b57c50c6@hastings.org> Message-ID: <882df9f6-fbb3-9e2b-c63a-af00028361f0@hastings.org> In reply to my proposal of a few days ago, I received two +1s and no other feedback. So I'm going to issue 3.4.7 with relatively-little notice.t Here's the schedule for 3.4.7; it mirrors the schedule for 3.5.4. Saturday, July 22, 2017 - tag 3.4.7 rc1 Sunday, July 23, 2017 - release 3.4.7 rc1 Sunday, August 6, 2017 - tag 3.4.7 final Monday, August 7, 2017 - release 3.4.7 final Cheers, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Sat Jul 15 08:29:45 2017 From: larry at hastings.org (Larry Hastings) Date: Sat, 15 Jul 2017 14:29:45 +0200 Subject: [python-committers] "trivial" label replaced with "skip issue" In-Reply-To: References: Message-ID: <06eb7c2c-959e-34f6-a786-267982e56931@hastings.org> On 07/14/2017 08:33 PM, Brett Cannon wrote: > 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) Sorry for the lack of communication; I've been traveling for two weeks and it's been stimulating. I plan to create the PRs during the EuroPython sprints (aka this weekend). //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Sat Jul 15 17:51:37 2017 From: nad at python.org (Ned Deily) Date: Sat, 15 Jul 2017 17:51:37 -0400 Subject: [python-committers] Python 3.3.7 release schedule and end-of-life Message-ID: <32CB89BE-A49E-4888-B8C7-4A8CAB8F15F1@python.org> Python 3.3 is fast approaching its end-of-life date, 2017-09-29. Per our release policy, that date is five years after the initial release of 3.3, 3.3.0 final on 2012-09-29. Note that 3.3 has been in security-fix only mode since the 2014-03-08 release of 3.3.5. It has been a while since we produced a 3.3.x security-fix release and, due to his commitments elsewhere, Georg has agreed for me to lead 3.3 to its well-deserved retirement. To that end, I would like to schedule its next, and hopefully final, security-fix release to coincide with the already announced 3.4.7 security-fix release. In particular, we'll plan to tag and release 3.3.7rc1 on Monday 2017-07-24 (UTC) and tag and release 3.3.7 final on Monday 2017-08-07. In the coming days, I'll be reviewing the outstanding 3.3 security issues and merging appropriate 3.3 PRs. Some of them have been sitting as patches for a long time so, if you have any such security issues that you think belong in 3.3, it would be very helpful if you would review such patches and turn them into 3.3 PRs. As a reminder, here are the guidelines from the devguide as to what is appropriate for a security-fix only branch: "The only changes made to a security branch are those fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch. You should also consider fixing hard-failing tests in open security branches since it is important to be able to run the tests successfully before releasing." Note that documentation changes, other than any that might be related to a security fix, are also out of scope. Assuming no new security issues arise prior to the EOL date, 3.3.7 will likely be the final release of 3.3. And you really shouldn't be using 3.3 at all at this point; while downstream distributors are, of course, free to provide support of 3.3 to their customers, in a little over two months when EOL is reached python-dev will no longer accept any issues or make any changes available for 3.3. If you are still using 3.3, you really owe it to your applications, to your users, and to yourself to upgrade to a more recent release of Python 3, preferably 3.6! Many, many fixes, new features, and substantial performance improvements await you. https://www.python.org/dev/peps/pep-0398/ https://devguide.python.org/devcycle/#security-branches -- Ned Deily nad at python.org -- [] From victor.stinner at gmail.com Sun Jul 16 10:10:11 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Sun, 16 Jul 2017 16:10:11 +0200 Subject: [python-committers] "trivial" label replaced with "skip issue" In-Reply-To: References: Message-ID: 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 converting old Misc/NEWS entries? Do you have an idea of many files we will get? Do we plan to remove old entries? Victor From larry at hastings.org Sun Jul 16 16:45:25 2017 From: larry at hastings.org (Larry Hastings) Date: Sun, 16 Jul 2017 22:45:25 +0200 Subject: [python-committers] "trivial" label replaced with "skip issue" In-Reply-To: References: Message-ID: <1ddfb890-7090-d4dc-efbf-c87f00deb4d2@hastings.org> Getting rid of Misc/NEWS was the whole point. The benefit is that we get rid of Misc/NEWS collisions. The other questions, you can answer for yourself by looking at the PRs. They're all in a row, PR 2714 through PR 2719. 2719 is where most of the conversation is happening. https://github.com/python/cpython/pull/2719 Right now I'm trying to figure out how to fix the Doc build. I don't think there are any other issues. //arry/ On 07/16/2017 04:10 PM, Victor Stinner wrote: > 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 converting old > Misc/NEWS entries? Do you have an idea of many files we will get? Do > we plan to remove old entries? > > Victor > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sun Jul 16 17:11:31 2017 From: brett at python.org (Brett Cannon) Date: Sun, 16 Jul 2017 21:11:31 +0000 Subject: [python-committers] "trivial" label replaced with "skip issue" In-Reply-To: References: Message-ID: On Sun, Jul 16, 2017, 07:10 Victor Stinner, wrote: > 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. Just a reminder all the major discussions about workflow changes happen on the core-workflow mailing list with smaller discussions on the core-workflow issue tracker. This specific change has been planned and discussed since the migration was nothing more than a PEP. -brett What is the benefit of converting old > Misc/NEWS entries? Do you have an idea of many files we will get? Do > we plan to remove old entries? > > Victor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sun Jul 16 17:15:00 2017 From: brett at python.org (Brett Cannon) Date: Sun, 16 Jul 2017 21:15:00 +0000 Subject: [python-committers] Python 3.3.7 release schedule and end-of-life In-Reply-To: <32CB89BE-A49E-4888-B8C7-4A8CAB8F15F1@python.org> References: <32CB89BE-A49E-4888-B8C7-4A8CAB8F15F1@python.org> Message-ID: A quick thanks from me, Ned, for stepping forward to help 3.3 pine for the fjords. On Sat, Jul 15, 2017, 14:51 Ned Deily, wrote: > Python 3.3 is fast approaching its end-of-life date, 2017-09-29. Per our > release policy, that date is five years after the initial release of 3.3, > 3.3.0 final on 2012-09-29. Note that 3.3 has been in security-fix only > mode since the 2014-03-08 release of 3.3.5. It has been a while since we > produced a 3.3.x security-fix release and, due to his commitments > elsewhere, Georg has agreed for me to lead 3.3 to its well-deserved > retirement. > > To that end, I would like to schedule its next, and hopefully final, > security-fix release to coincide with the already announced 3.4.7 > security-fix release. In particular, we'll plan to tag and release 3.3.7rc1 > on Monday 2017-07-24 (UTC) and tag and release 3.3.7 final on Monday > 2017-08-07. In the coming days, I'll be reviewing the outstanding 3.3 > security issues and merging appropriate 3.3 PRs. Some of them have been > sitting as patches for a long time so, if you have any such security issues > that you think belong in 3.3, it would be very helpful if you would review > such patches and turn them into 3.3 PRs. > > As a reminder, here are the guidelines from the devguide as to what is > appropriate for a security-fix only branch: > > "The only changes made to a security branch are those fixing issues > exploitable by attackers such as crashes, privilege escalation and, > optionally, other issues such as denial of service attacks. Any other > changes are not considered a security risk and thus not backported to a > security branch. You should also consider fixing hard-failing tests in open > security branches since it is important to be able to run the tests > successfully before releasing." > > Note that documentation changes, other than any that might be related to a > security fix, are also out of scope. > > Assuming no new security issues arise prior to the EOL date, 3.3.7 will > likely be the final release of 3.3. And you really shouldn't be using 3.3 > at all at this point; while downstream distributors are, of course, free to > provide support of 3.3 to their customers, in a little over two months when > EOL is reached python-dev will no longer accept any issues or make any > changes available for 3.3. If you are still using 3.3, you really owe it > to your applications, to your users, and to yourself to upgrade to a more > recent release of Python 3, preferably 3.6! Many, many fixes, new > features, and substantial performance improvements await you. > > https://www.python.org/dev/peps/pep-0398/ > https://devguide.python.org/devcycle/#security-branches > > -- > Ned Deily > nad at python.org -- [] > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Sun Jul 16 18:21:39 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 17 Jul 2017 00:21:39 +0200 Subject: [python-committers] "trivial" label replaced with "skip issue" In-Reply-To: References: Message-ID: 2017-07-16 16:10 GMT+02:00 Victor Stinner : > 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 of many files we will get? > Do we plan to remove old entries? Before: 47 files in master. After: 546 files. Ok, it's not much. I didn't know that blurb supports "packing" NEWS entries into a single file, like Misc/NEWS.d/3.5.0a1.rst which contains 598 entries. Cool! My fear was to get 10,000 files in Misc/NEWS and starting to get performance issues with Git on some platforms. With the PR #2719 (convert Misc/NEWS to blurb for master), the Git repository contains 4,340 files. On my laptop, I didn't notice any major performance related to that. Victor From nad at python.org Mon Jul 17 01:50:33 2017 From: nad at python.org (Ned Deily) Date: Mon, 17 Jul 2017 01:50:33 -0400 Subject: [python-committers] [RELEASE] Python 3.6.2 is now available Message-ID: On behalf of the Python development community and the Python 3.6 release team, I am happy to announce the availability of Python 3.6.2, the second maintenance release of Python 3.6. 3.6.0 was released on 2016-12-22 to great interest and we are now providing the second set of bugfixes and documentation updates for it; the first maintenance release, 3.6.1, was released on 2017-03-31. Detailed information about the changes made in 3.6.2 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-2 Please see "What?s New In Python 3.6" for more information about the new features in Python 3.6: https://docs.python.org/3.6/whatsnew/3.6.html You can download Python 3.6.2 here: https://www.python.org/downloads/release/python-362/ The next maintenance release of Python 3.6 is expected to follow in about 3 months, around the end of 2017-09. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ Enjoy! P.S. If you need to download the documentation set for 3.6.2 immediately, you can always find the release version here: https://docs.python.org/release/3.6.2/download.html The most current updated versions will appear here: https://docs.python.org/3.6/ -- Ned Deily nad at python.org -- [] From antoine at python.org Mon Jul 17 06:25:03 2017 From: antoine at python.org (Antoine Pitrou) Date: Mon, 17 Jul 2017 12:25:03 +0200 Subject: [python-committers] AppVeyor off? Message-ID: Hi, Is AppVeyor turned off these days? I don't see a build on https://github.com/python/cpython/pull/2417 Regards Antoine. From antoine at python.org Mon Jul 17 07:29:54 2017 From: antoine at python.org (Antoine Pitrou) Date: Mon, 17 Jul 2017 13:29:54 +0200 Subject: [python-committers] AppVeyor off? In-Reply-To: References: Message-ID: Nevermind, it seems to have come back online. Le 17/07/2017 ? 12:25, Antoine Pitrou a ?crit : > > Hi, > > Is AppVeyor turned off these days? I don't see a build on > https://github.com/python/cpython/pull/2417 > > Regards > > Antoine. > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > From ncoghlan at gmail.com Mon Jul 17 08:51:30 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 17 Jul 2017 22:51:30 +1000 Subject: [python-committers] AppVeyor off? In-Reply-To: References: Message-ID: On 17 July 2017 at 21:29, Antoine Pitrou wrote: > > Nevermind, it seems to have come back online. I've occasionally seen that not just with Appveyor, but also with other pre-merge CI systems: it seems like their event monitoring queue and/or task scheduler can get backed up (sometimes significantly), so it takes them a while to report back that they've seen the PR and have a test run scheduled. Travis is the most reliable I've seen when it comes to getting their "Result pending" status back in promptly, so my assumption is that they actually send that back before (or in parallel with) scheduling the CI run itself. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brett at python.org Mon Jul 17 16:16:17 2017 From: brett at python.org (Brett Cannon) Date: Mon, 17 Jul 2017 20:16:17 +0000 Subject: [python-committers] "trivial" label replaced with "skip issue" In-Reply-To: References: Message-ID: On Sun, 16 Jul 2017 at 15:22 Victor Stinner wrote: > 2017-07-16 16:10 GMT+02:00 Victor Stinner : > > 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. > It's to ease backporting since you will never have Misc/NEWS have a merge conflict ever again. > > > Do you have an idea of many files we will get? > > Do we plan to remove old entries? > > Before: 47 files in master. > After: 546 files. Ok, it's not much. > > I didn't know that blurb supports "packing" NEWS entries into a single > file, like Misc/NEWS.d/3.5.0a1.rst which contains 598 entries. Cool! > > My fear was to get 10,000 files in Misc/NEWS and starting to get > performance issues with Git on some platforms. > Yeah, I already had that fear for you. :) > > With the PR #2719 (convert Misc/NEWS to blurb for master), the Git > repository contains 4,340 files. On my laptop, I didn't notice any > major performance related to that. > That was a design goal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon Jul 17 16:40:05 2017 From: brett at python.org (Brett Cannon) Date: Mon, 17 Jul 2017 20:40:05 +0000 Subject: [python-committers] AppVeyor off? In-Reply-To: References: Message-ID: On Mon, 17 Jul 2017 at 05:52 Nick Coghlan wrote: > On 17 July 2017 at 21:29, Antoine Pitrou wrote: > > > > Nevermind, it seems to have come back online. > > I've occasionally seen that not just with Appveyor, but also with > other pre-merge CI systems: it seems like their event monitoring queue > and/or task scheduler can get backed up (sometimes significantly), so > it takes them a while to report back that they've seen the PR and have > a test run scheduled. > > Travis is the most reliable I've seen when it comes to getting their > "Result pending" status back in promptly, so my assumption is that > they actually send that back before (or in parallel with) scheduling > the CI run itself. > There's also race condition issues between GitHub's webhook events and when the API actually exposes the data that triggered the webhook (this is why both the Knights Who Say Ni and Bedevere bots have a forced delay before updating a PR). I don't know if AppVeyor heavily delays trying again if the initial status setting fails, but it's possible. I should also mention I try to announce anything that is a visible change to our workflow here, so if I haven't said anything was turned off, assume it broke. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Tue Jul 18 05:34:26 2017 From: antoine at python.org (Antoine Pitrou) Date: Tue, 18 Jul 2017 11:34:26 +0200 Subject: [python-committers] CLA bot bug for a particular contributor Message-ID: <64e990b9-f8d7-1d2c-bf56-75b37cf945a1@python.org> Hi, How can I get the CLA bot to fix its knowledge for a particular contributor? bugs.python.org user Gareth Rees (https://bugs.python.org/user14554) has signed the CLA and filled in his GitHub username "gareth-rees". However, a PR filed by Gareth (https://github.com/python/cpython/pull/2741) has the "CLA not signed" label added. I could fix that particular label myself but am I wrong in thinking that further PRs would still have the wrong label assigned? Regards Antoine. From antoine at python.org Tue Jul 18 05:36:05 2017 From: antoine at python.org (Antoine Pitrou) Date: Tue, 18 Jul 2017 11:36:05 +0200 Subject: [python-committers] "trivial" label replaced with "skip issue" In-Reply-To: References: Message-ID: <98b6b3cb-14d8-c4fa-8f49-cd1d7e2f9a3b@python.org> Le 17/07/2017 ? 22:16, Brett Cannon a ?crit : > > > On Sun, 16 Jul 2017 at 15:22 Victor Stinner > wrote: > > 2017-07-16 16:10 GMT+02:00 Victor Stinner >: > > 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. > > > It's to ease backporting since you will never have Misc/NEWS have a > merge conflict ever again. 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. From victor.stinner at gmail.com Tue Jul 18 05:36:50 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 18 Jul 2017 11:36:50 +0200 Subject: [python-committers] CLA bot bug for a particular contributor In-Reply-To: <64e990b9-f8d7-1d2c-bf56-75b37cf945a1@python.org> References: <64e990b9-f8d7-1d2c-bf56-75b37cf945a1@python.org> Message-ID: 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 user Gareth Rees (https://bugs.python.org/user14554) has > signed the CLA and filled in his GitHub username "gareth-rees". > > However, a PR filed by Gareth > (https://github.com/python/cpython/pull/2741) has the "CLA not signed" > label added. I could fix that particular label myself but am I wrong in > thinking that further PRs would still have the wrong label assigned? > > Regards > > Antoine. > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From victor.stinner at gmail.com Tue Jul 18 06:24:13 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 18 Jul 2017 12:24:13 +0200 Subject: [python-committers] My (positive) feedback on the new CPython workflow Message-ID: 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 with the new workflow. The code became better, many things are much simpler for me (especially the tasks that I don't have to do myself anymore ;-)), my productivity increases and I see more and more active contributors, much more than before the move to GitHub and new workflow! == Introduction == Two friends asked me recently how is the new Python workflow going. Somehow, I decided to not express myself on the topic to avoid dummy knee-jerk reaction like "it sucks, it was better before, xxx doesn't work, now I have to xxx, etc." It took me at least 3 months to be used to the new workflow, while tools were developed and enhanced, and the workflow was adjusted based on our early feedback. So, here is my feedback :-) == pre-commit CI: less regressions == >From a pure technical point of view, IMHO pre-commit CI on Linux (Travis CI) and Windows (AppVeyor) is a *MAJOR* enhancement. (I don't count macOS, since it's not mandatory yet.) For example, before GitHub, it was common to break Windows since too few core developers were running tests *manually* on Windows. It's hard to prove my point, so try to trust me: we reduce a lot the number of regressions introduced by new changesets. Before, every two weeks, we had to rush to push fixes in urgency (which sometimes leaded to bad code which required multiple iterations until we find the best fix). It was especially annoying when a dev pushed a big change just before being away for 8-12 hours, which means having to push a fix without the review of the change author :-( == More contributors, more contributions, faster reviewed/merged == In term of contributions, I looked at statistics yesterday and it became clear the number of different authors is significantely much higher, around 25 contributors / month before, now closer to 50: https://www.openhub.net/p/python/contributors/summary Well, Git allows to store the original author, so statistics are simplify higher just because previously the tools failed to identify the real author. But I'm watching the bug tracker, pull requests, and Git commits: there are a lot of *new* contributors, we get more contributions, and we are *faster* to integrate them. I also saw again inactive core contributors starting to review again, or even write new PRs! It's a very good sign of the good health of our project! More generally, the whole development seems to be more active, more productive and more *healthy*. == Better scale horizontally == The new workflow better scales horizontally since we delegated much more work to the contributor. Previously the core developers were more the bottleneck. Tasks delegated to the contributors: * create the PR itself (can you still remind when we had to download a patch file and create a commit? ;-)), * write the commit message (I always hated to do that without any kind of review...), * add the NEWS entry (before it was common to explicitly ask to *not* write it... to avoid conflicts with Misc/NEWS...). * most contributors create backports (using cherry-pick) themself. Before, this painful/error-prone task was usually done by a single developer without any review, without pre-commit tests, etc. Note: I didn't see any contributor complaining about having to do these tasks. It seems like it's more the opposite, they are happy to be more *involved* in the project! == GitHub == I never had to explain how to create an account on GitHub, nor how to create a PR. Signing the CLA doesn't seem to be a blocker point neither, contributors are able to sign it and the bot tracks correctly the CLA status (thanks Brett for the bot! it's nice to feel safe for legal issues ;-)). Maybe we have an excellent documentation. Maybe developers already know well the GitHub platform. Even for backports, I didn't have to explain how to cherry-pick a commit, but it was common that I pointed to the devguide section when I proposed the author to do the backport himself/herself. Having explicitly a list of "Approve" and "Requet changes" votes helps to *quickly* have an overview of the review status. I'm just not unconfortable with the fact that an approval is kept even if the PR is modified after the review :-/ I would expect a list a notice "changed modified after the review" or something like that. At least, for my own reviews, to remind me to review again. The [First time contributor] label on PR helps to remind Misc/ACKS: ask the author to add himself/herself to ACKS. Compared to Rietveld, GitHub review tool is as "a good" (not much better, not much worse). Sometimes, I'm lost in reviews: my comments are hidden, I have to unfold many widgets. But it's not that bad. It seems like avoiding rebase works around some of these issues. == Git branches == Having to create a local Git branch, push it to my repository and create PR is more work than attaching a patch file to bugs.python.org. It requires to be more organized to track my "local" Git branches. I'm now trying to remove a local branch after pushing the PR, since it also exists in my "haypo" remote anyway. It helps to have a shorter list of branches. I also wrote a shell script to run "git fetch haypo --prune" to remove "merged" branches (technically, I have to click on a button to remove my branch, after I merge my own PR). Sometimes, I also see branches in the upstream repository (python/cpython), but it seems that we have less and less of them. == NEWS.d and blurb == Thank you Larry Hastings, Brett Cannon and others who helped to write and integrate blurb: no more Misc/NEWS conflict, it's just amazing :-) We *all* wanted that for *years*! Victor From storchaka at gmail.com Tue Jul 18 07:36:19 2017 From: storchaka at gmail.com (Serhiy Storchaka) Date: Tue, 18 Jul 2017 14:36:19 +0300 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: 18.07.17 13:24, Victor Stinner ????: > == More contributors, more contributions, faster reviewed/merged == > > In term of contributions, I looked at statistics yesterday and it > became clear the number of different authors is significantely much > higher, around 25 contributors / month before, now closer to 50: > https://www.openhub.net/p/python/contributors/summary > > Well, Git allows to store the original author, so statistics are > simplify higher just because previously the tools failed to identify > the real author. > > But I'm watching the bug tracker, pull requests, and Git commits: > there are a lot of *new* contributors, we get more contributions, and > we are *faster* to integrate them. > > I also saw again inactive core contributors starting to review again, > or even write new PRs! It's a very good sign of the good health of our > project! > > More generally, the whole development seems to be more active, more > productive and more *healthy*. I have a different impression. Some core developers (like Raymond or Martin) stopped committing even if they are active on the bug tracker or mailing lists. Others make much less commits than they did before the migration. I rather like the new workflow (except few lost features), but I afraid than many core developers are feeling uncomfortable with it. From antoine at python.org Tue Jul 18 07:40:03 2017 From: antoine at python.org (Antoine Pitrou) Date: Tue, 18 Jul 2017 13:40:03 +0200 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: Le 18/07/2017 ? 13:36, Serhiy Storchaka a ?crit : > > I have a different impression. Some core developers (like Raymond or > Martin) stopped committing even if they are active on the bug tracker or > mailing lists. Others make much less commits than they did before the > migration. Assuming you meant Martin von L?wis, I think Martin stopped contributing long before we migrated to git (unfortunately, I might add). I hope he's doing ok. Regards Antoine. From ncoghlan at gmail.com Tue Jul 18 07:56:30 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 18 Jul 2017 21:56:30 +1000 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: On 18 July 2017 at 21:36, Serhiy Storchaka wrote: > I rather like the new workflow (except few lost features), but I afraid than > many core developers are feeling uncomfortable with it. Aye, I think for folks already familiar with git and PR-style workflows through other projects, it's been almost a pure win, especially as various aspects have become more automated. However, for folks that *weren't* already familiar with those, it's a pretty steep learning curve, and one accompanied by a non-trivial increase in the overall pace of development. So in addition to thanking the folks working on the migration and the associated automation, I'd also like to explicitly thank Mariatta, Terry, Zachary, and everyone else that has contributed to the git cheatsheet and other workflow documentation updates in the developer's guide. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From antoine at python.org Tue Jul 18 07:57:23 2017 From: antoine at python.org (Antoine Pitrou) Date: Tue, 18 Jul 2017 13:57:23 +0200 Subject: [python-committers] Unreliable contributor stats In-Reply-To: References: Message-ID: Le 18/07/2017 ? 12:24, Victor Stinner a ?crit : > > == More contributors, more contributions, faster reviewed/merged == > > In term of contributions, I looked at statistics yesterday and it > became clear the number of different authors is significantely much > higher, around 25 contributors / month before, now closer to 50: > https://www.openhub.net/p/python/contributors/summary Beware of how those numbers are calculated. When we were using hg, patches were typically committed by core developers, so only core developers appeared as "contributors" in the hg log. Now we're using GitHub, commits are made by their contributors themselves, so the git log now shows their names. (note the difference is really GitHub PRs vs. applying-patches-by-hand, not git vs. hg) Furthermore, based on https://www.openhub.net/p/python/commits/summary, it seems the latest stats collected by OpenHub date back to 30th May 2017. They are two months late. Regards Antoine. From storchaka at gmail.com Tue Jul 18 07:59:53 2017 From: storchaka at gmail.com (Serhiy Storchaka) Date: Tue, 18 Jul 2017 14:59:53 +0300 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: 18.07.17 14:40, Antoine Pitrou ????: > Assuming you meant Martin von L?wis, I think Martin stopped contributing > long before we migrated to git (unfortunately, I might add). I hope > he's doing ok. I meant Martin Panter. His was the third of most active committers recent two years, but didn't commit anything recent months. From antoine at python.org Tue Jul 18 11:33:11 2017 From: antoine at python.org (Antoine Pitrou) Date: Tue, 18 Jul 2017 17:33:11 +0200 Subject: [python-committers] "Invalid symmetric difference expression" on Travis-CI Message-ID: Hi, I've just got this weird error on Travis-CI (the build itself is still marked green, which is great :-D): https://travis-ci.org/python/cpython/jobs/254906991 """ $ set -e if ! git diff --name-only $TRAVIS_COMMIT_RANGE | grep -qvE '(\.rst$)|(^Doc)|(^Misc)' then echo "Only docs were updated, stopping build process." exit fi ./configure --with-pydebug make -j4 make -j4 regen-all clinic changes=`git status --porcelain` if ! test -z "$changes" then echo "Generated files not up to date" echo "$changes" exit 1 fi fatal: Invalid symmetric difference expression 8a8d28501fc8ce25926d168f1c657656c809fd4c...84e0e7a063215809b81e59ab7f59c8bf44492aa8 Only docs were updated, stopping build process. """ Regards Antoine. From victor.stinner at gmail.com Tue Jul 18 11:48:05 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 18 Jul 2017 17:48:05 +0200 Subject: [python-committers] Unreliable contributor stats In-Reply-To: References: Message-ID: 2017-07-18 13:57 GMT+02:00 Antoine Pitrou : > Beware of how those numbers are calculated. > > When we were using hg, patches were typically committed by core > developers, so only core developers appeared as "contributors" in the hg > log. Right, that's why I wrote: "Well, Git allows to store the original author, so statistics are simplify higher just because previously the tools failed to identify the real author." I asked Mercurial developers if they would like to add a "committer" field, but this feature was never implemented :-( Victor From antoine at python.org Tue Jul 18 12:20:26 2017 From: antoine at python.org (Antoine Pitrou) Date: Tue, 18 Jul 2017 18:20:26 +0200 Subject: [python-committers] How do I kill an AppVeyor build? Message-ID: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Hi, It seems only some select people have the ability to kill or re-launch AppVeyor builds? Regards Antoine. From p.f.moore at gmail.com Tue Jul 18 12:26:34 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 18 Jul 2017 17:26:34 +0100 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: You need to log on as the Appveyor account in order to manage builds. It's possible to link a Github team with an Appveyor admin role to allow the team to all have the ability to (effectively) log in as the appveyor account. It's a bit fiddly to set up (and use :-() but it does work. If whoever currently owns the cpython appveyor account wants help setting things up, I've done it for pip so I can assist. Paul On 18 July 2017 at 17:20, Antoine Pitrou wrote: > > Hi, > > It seems only some select people have the ability to kill or re-launch > AppVeyor builds? > > Regards > > Antoine. > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From brett at python.org Tue Jul 18 13:23:28 2017 From: brett at python.org (Brett Cannon) Date: Tue, 18 Jul 2017 17:23:28 +0000 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: I set up the account and Zach has access. If you have instructions to point me at, Paul, I can see if I can set it up. On Tue, 18 Jul 2017 at 09:26 Paul Moore wrote: > You need to log on as the Appveyor account in order to manage builds. > It's possible to link a Github team with an Appveyor admin role to > allow the team to all have the ability to (effectively) log in as the > appveyor account. It's a bit fiddly to set up (and use :-() but it > does work. If whoever currently owns the cpython appveyor account > wants help setting things up, I've done it for pip so I can assist. > > Paul > > On 18 July 2017 at 17:20, Antoine Pitrou wrote: > > > > Hi, > > > > It seems only some select people have the ability to kill or re-launch > > AppVeyor builds? > > > > Regards > > > > Antoine. > > _______________________________________________ > > python-committers mailing list > > python-committers at python.org > > https://mail.python.org/mailman/listinfo/python-committers > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Tue Jul 18 14:06:35 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 18 Jul 2017 19:06:35 +0100 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: I'll get something for you, but it may not be for a couple of days. Paul On 18 July 2017 at 18:23, Brett Cannon wrote: > I set up the account and Zach has access. If you have instructions to point > me at, Paul, I can see if I can set it up. > > > On Tue, 18 Jul 2017 at 09:26 Paul Moore wrote: >> >> You need to log on as the Appveyor account in order to manage builds. >> It's possible to link a Github team with an Appveyor admin role to >> allow the team to all have the ability to (effectively) log in as the >> appveyor account. It's a bit fiddly to set up (and use :-() but it >> does work. If whoever currently owns the cpython appveyor account >> wants help setting things up, I've done it for pip so I can assist. >> >> Paul >> >> On 18 July 2017 at 17:20, Antoine Pitrou wrote: >> > >> > Hi, >> > >> > It seems only some select people have the ability to kill or re-launch >> > AppVeyor builds? >> > >> > Regards >> > >> > Antoine. >> > _______________________________________________ >> > python-committers mailing list >> > python-committers at python.org >> > https://mail.python.org/mailman/listinfo/python-committers >> > Code of Conduct: https://www.python.org/psf/codeofconduct/ >> _______________________________________________ >> python-committers mailing list >> python-committers at python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ From zachary.ware+pydev at gmail.com Tue Jul 18 14:07:53 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Tue, 18 Jul 2017 13:07:53 -0500 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon wrote: > I set up the account and Zach has access. If you have instructions to point > me at, Paul, I can see if I can set it up. Looks like https://ci.appveyor.com/gitHubTeams while logged in as 'python'. That looks like the right place to make the changes, anyway; I haven't tried to actually make any :) -- Zach From p.f.moore at gmail.com Tue Jul 18 14:15:57 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 18 Jul 2017 19:15:57 +0100 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: That's the one. If you select the github team you want (for PyPA I set up an "Appveyor Admins" team) and choose the Administrator role. That may well be all you need to do - I don't recall if you need to do anything on the github side. Once you do that, people in the relevant github group, when logging into Appveyor with github will get a message "Specified user belongs to multiple accounts" and the "Account" dropdown will contain their own account and "python". They need to select "python" to get the option to manage (cancel or restart) builds. One reason we might want to restrict access is that logging in like this gives the user full access to the Appveyor account, including (as far as I can tell) the ability to grant further privileges. It's possible to create additional roles, but I don't see a "Cancel and restart builds" privilege. I think that's all that's needed - give me a shout if I've missed anything. Paul On 18 July 2017 at 19:07, Zachary Ware wrote: > On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon wrote: >> I set up the account and Zach has access. If you have instructions to point >> me at, Paul, I can see if I can set it up. > > Looks like https://ci.appveyor.com/gitHubTeams while logged in as 'python'. > > That looks like the right place to make the changes, anyway; I haven't > tried to actually make any :) > > -- > Zach > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From p.f.moore at gmail.com Tue Jul 18 14:17:32 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 18 Jul 2017 19:17:32 +0100 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: BTW, the docs for all this are at https://www.appveyor.com/docs/team-setup/#github-integration although I found them a bit hard to follow, personally. Paul On 18 July 2017 at 19:15, Paul Moore wrote: > That's the one. If you select the github team you want (for PyPA I set > up an "Appveyor Admins" team) and choose the Administrator role. That > may well be all you need to do - I don't recall if you need to do > anything on the github side. > > Once you do that, people in the relevant github group, when logging > into Appveyor with github will get a message "Specified user belongs > to multiple accounts" and the "Account" dropdown will contain their > own account and "python". They need to select "python" to get the > option to manage (cancel or restart) builds. > > One reason we might want to restrict access is that logging in like > this gives the user full access to the Appveyor account, including (as > far as I can tell) the ability to grant further privileges. It's > possible to create additional roles, but I don't see a "Cancel and > restart builds" privilege. > > I think that's all that's needed - give me a shout if I've missed anything. > Paul > > > On 18 July 2017 at 19:07, Zachary Ware wrote: >> On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon wrote: >>> I set up the account and Zach has access. If you have instructions to point >>> me at, Paul, I can see if I can set it up. >> >> Looks like https://ci.appveyor.com/gitHubTeams while logged in as 'python'. >> >> That looks like the right place to make the changes, anyway; I haven't >> tried to actually make any :) >> >> -- >> Zach >> _______________________________________________ >> python-committers mailing list >> python-committers at python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ From brett at python.org Tue Jul 18 14:31:00 2017 From: brett at python.org (Brett Cannon) Date: Tue, 18 Jul 2017 18:31:00 +0000 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: On Tue, 18 Jul 2017 at 03:24 Victor Stinner wrote: > 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. > Glad it's working out! And a thanks from me to everyone who participated in the discussions that led to blurb (and of course Larry for coding it up and putting up with me throughout the whole process :) . > > > > Regards > > > > Antoine. > > I concur with Antoine, I'm now *very* happy with the new workflow. The > code became better, many things are much simpler for me (especially > the tasks that I don't have to do myself anymore ;-)), my productivity > increases and I see more and more active contributors, much more than > before the move to GitHub and new workflow! > Great! That was the goal the whole time so I'm glad it's starting to pay off. > > > == Introduction == > > Two friends asked me recently how is the new Python workflow going. > > Somehow, I decided to not express myself on the topic to avoid dummy > knee-jerk reaction like "it sucks, it was better before, xxx doesn't > work, now I have to xxx, etc." > > It took me at least 3 months to be used to the new workflow, while > tools were developed and enhanced, and the workflow was adjusted based > on our early feedback. > > So, here is my feedback :-) > > > == pre-commit CI: less regressions == > > From a pure technical point of view, IMHO pre-commit CI on Linux > (Travis CI) and Windows (AppVeyor) is a *MAJOR* enhancement. (I don't > count macOS, since it's not mandatory yet.) > > For example, before GitHub, it was common to break Windows since too > few core developers were running tests *manually* on Windows. > > It's hard to prove my point, so try to trust me: we reduce a lot the > number of regressions introduced by new changesets. Before, every two > weeks, we had to rush to push fixes in urgency (which sometimes leaded > to bad code which required multiple iterations until we find the best > fix). > > It was especially annoying when a dev pushed a big change just before > being away for 8-12 hours, which means having to push a fix without > the review of the change author :-( > I have to admit I also appreciate the CI testing a lot since I worry a lot less about whether Python is in some broken state. And then thanks to all the hard work you've done, Victor, we know that if the buildbots go red that we have actually regressed and need to roll back a change instead of going "that buildbot is just always broken so you can ignore it". It's getting to the point that I'm toying with the idea of making a Google Assistant command for my Google Home so I can say, "Hey Google, how is CPython doing?" and have it tell me if the buildbots are all green. :) And I still dream about having some LED light or grid for sprints where we can visibly see the buildbot statuses to know quickly when something has broken. But none of that was possible previously, so it's really exciting to have reached a stability point where this isn't a stupid idea. :) > > > == More contributors, more contributions, faster reviewed/merged == > > In term of contributions, I looked at statistics yesterday and it > became clear the number of different authors is significantely much > higher, around 25 contributors / month before, now closer to 50: > https://www.openhub.net/p/python/contributors/summary > > Well, Git allows to store the original author, so statistics are > simplify higher just because previously the tools failed to identify > the real author. > I'm going to be interested to see how the numbers look in Feb 2018 compared to now and see if there's a trend since the transition. > > But I'm watching the bug tracker, pull requests, and Git commits: > there are a lot of *new* contributors, we get more contributions, and > we are *faster* to integrate them. > > I also saw again inactive core contributors starting to review again, > or even write new PRs! It's a very good sign of the good health of our > project! > As Serhiy pointed out, though, some people have not made the transition. To help with this I plan on offering to do video chats with any core devs who want a personal walkthrough of the workflow, but I'm holding off on that until all of the critical workflow changes have landed as I don't want to be talking with someone and saying, "but this will be changing in a month or so". :) > > More generally, the whole development seems to be more active, more > productive and more *healthy*. > > > == Better scale horizontally == > > The new workflow better scales horizontally since we delegated much > more work to the contributor. Previously the core developers were more > the bottleneck. > > Tasks delegated to the contributors: > > * create the PR itself (can you still remind when we had to download a > patch file and create a commit? ;-)), > > * write the commit message (I always hated to do that without any kind > of review...), > > * add the NEWS entry (before it was common to explicitly ask to *not* > write it... to avoid conflicts with Misc/NEWS...). > Once again, glad the goals are panning out. :) Key thing has always been to increase our bandwidth and part of that was always to push more on to contributors so they can be more self-servicing. > > * most contributors create backports (using cherry-pick) themself. > Before, this painful/error-prone task was usually done by a single > developer without any review, without pre-commit tests, etc. > Nice! Maybe we should have a message from Bedevere after a PR gets merged saying something like, "thanks for the PR and congrats on getting it merged! If you're interested in helping to backport your PR to older versions of Python, let us know and follow the instructions at XXX to create backporting PRs." > > Note: I didn't see any contributor complaining about having to do > these tasks. It seems like it's more the opposite, they are happy to > be more *involved* in the project! > > > == GitHub == > > I never had to explain how to create an account on GitHub, nor how to > create a PR. > > Signing the CLA doesn't seem to be a blocker point neither, > contributors are able to sign it and the bot tracks correctly the CLA > status (thanks Brett for the bot! it's nice to feel safe for legal > issues ;-)). > Yeah, I sleep a little better at night thanks to that thing. :) > > Maybe we have an excellent documentation. Maybe developers already > know well the GitHub platform. > > Even for backports, I didn't have to explain how to cherry-pick a > commit, but it was common that I pointed to the devguide section when > I proposed the author to do the backport himself/herself. > > Having explicitly a list of "Approve" and "Requet changes" votes helps > to *quickly* have an overview of the review status. > > I'm just not unconfortable with the fact that an approval is kept even > if the PR is modified after the review :-/ I would expect a list a > notice "changed modified after the review" or something like that. At > least, for my own reviews, to remind me to review again. > That wouldn't be too hard to add. I'm currently working on https://github.com/python/core-workflow/issues/94 which is going to label PRs based on their current stage (much like the stage field on bugs.python.org but much more automated). One of the labels is going to be "awaiting change review" for when a contributor has addressed requested changes, but it could be applied when the latest review is an approval but a post-approval change was made (along w/ a comment to point out that's why the label was added). Does that sound like what you're after? > > The [First time contributor] label on PR helps to remind Misc/ACKS: > ask the author to add himself/herself to ACKS. > That's a great trick! I really wish we could programmatically access that more easily than scouring the git repo for committer details. > > Compared to Rietveld, GitHub review tool is as "a good" (not much > better, not much worse). Sometimes, I'm lost in reviews: my comments > are hidden, I have to unfold many widgets. But it's not that bad. It > seems like avoiding rebase works around some of these issues. > > > == Git branches == > > Having to create a local Git branch, push it to my repository and > create PR is more work than attaching a patch file to bugs.python.org. > It requires to be more organized to track my "local" Git branches. > > I'm now trying to remove a local branch after pushing the PR, since it > also exists in my "haypo" remote anyway. It helps to have a shorter > list of branches. > > I also wrote a shell script to run "git fetch haypo --prune" to remove > "merged" branches (technically, I have to click on a button to remove > my branch, after I merge my own PR). > > Sometimes, I also see branches in the upstream repository > (python/cpython), but it seems that we have less and less of them. > I think people are pretty good about cleaning up after themselves since those branches usually only come up when someone makes a change through the web UI. > > > == NEWS.d and blurb == > > Thank you Larry Hastings, Brett Cannon and others who helped to write > and integrate blurb: no more Misc/NEWS conflict, it's just amazing :-) > We *all* wanted that for *years*! > Just to keep people up-to-date with what I personally have planned or I know people are working on: 1. Status check for a news entry ( https://github.com/python/bedevere/pull/22) 2. Add a link to the end of the PR body back to bugs.python.org (thanks to Kushal; https://github.com/python/bedevere/issues/3 and https://github.com/python/bedevere/pull/24) 3. Label PRs based on what stage they are at ( https://github.com/python/core-workflow/issues/94; started work on this) 4. Make the CLA bot a status check instead of a label to make it a required status check ( https://github.com/python/the-knights-who-say-ni/issues/42) 5. Commit emails w/ diffs (thanks to Berker; https://github.com/python/bedevere/pull/27) I think #2 and #5 cover the last initial complains people had about the new workflow, #1 and #3 will make things even better, and #4 is so I can sleep even better at night. ;) My wishlist that I don't think anyone is actively working on ATM is: 1. Bot to merge approved PRs (e.g. Rust's Homu) 2. Bot to backport PRs (which could also be automatically merged) 3. Automate Misc/ACKS (or do away with it and do something like https://thanks.rust-lang.org/) 4. Make test coverage reports consistent 5. Automatically close stale PRs (e.g. not signing CLA, changes requested but not being made, etc.) 6. Bot to nudge core devs when they forget something (e.g. post-merge, a comment if someone forgot to change the commit message or PR number to have a "GH-" prefix) I think that wishlist would get us as automated as reasonably possible while reminding people when the manual parts are accidentally done wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Tue Jul 18 15:21:26 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Tue, 18 Jul 2017 15:21:26 -0400 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: <20170718192126.88ABF1B10016@webabinitio.net> On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner wrote: > I'm just not unconfortable with the fact that an approval is kept even > if the PR is modified after the review :-/ I would expect a list a > notice "changed modified after the review" or something like that. At > least, for my own reviews, to remind me to review again. This could be changed if we have consensus to do so. Github has a setting that will cause existing approvals to be "dismissed" if a new commit is pushed. > Compared to Rietveld, GitHub review tool is as "a good" (not much > better, not much worse). Sometimes, I'm lost in reviews: my comments > are hidden, I have to unfold many widgets. But it's not that bad. It > seems like avoiding rebase works around some of these issues. I much prefer rietveld over github reviews, but I also much prefer the integration between the bug tracker and github over the minimal integration we had for rietveld. Thanks to all the people who made that happen, and especially Brett for leading it. --David From barry at python.org Tue Jul 18 15:53:56 2017 From: barry at python.org (Barry Warsaw) Date: Tue, 18 Jul 2017 15:53:56 -0400 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: <20170718192126.88ABF1B10016@webabinitio.net> References: <20170718192126.88ABF1B10016@webabinitio.net> Message-ID: On Jul 18, 2017, at 15:21, R. David Murray wrote: > > I much prefer rietveld over github reviews, but I also much prefer the > integration between the bug tracker and github over the minimal > integration we had for rietveld. Thanks to all the people who made > that happen, and especially Brett for leading it. Not that I?m suggesting anything should change, but just FWIW, I find Gitlab to have a much better conversational review tool than Github. I often find myself getting lost in GH reviews (on many projects), but GL just organizes the conversation really well IMHO. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brett at python.org Tue Jul 18 15:59:27 2017 From: brett at python.org (Brett Cannon) Date: Tue, 18 Jul 2017 19:59:27 +0000 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: On Tue, 18 Jul 2017 at 11:08 Zachary Ware wrote: > On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon wrote: > > I set up the account and Zach has access. If you have instructions to > point > > me at, Paul, I can see if I can set it up. > > Looks like https://ci.appveyor.com/gitHubTeams while logged in as > 'python'. > > That looks like the right place to make the changes, anyway; I haven't > tried to actually make any :) > I went ahead and clicked buttons. :) I set Python core as users and release managers as admins (on top of Zach and me already being admins). -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Tue Jul 18 16:09:38 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 18 Jul 2017 22:09:38 +0200 Subject: [python-committers] Dismiss review if a PR is modified Message-ID: 2017-07-18 21:21 GMT+02:00 R. David Murray : > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner wrote: >> I'm just not unconfortable with the fact that an approval is kept even >> if the PR is modified after the review :-/ I would expect a list a >> notice "changed modified after the review" or something like that. At >> least, for my own reviews, to remind me to review again. > > This could be changed if we have consensus to do so. Github has a > setting that will cause existing approvals to be "dismissed" if > a new commit is pushed. > >> Compared to Rietveld, GitHub review tool is as "a good" (not much >> better, not much worse). Sometimes, I'm lost in reviews: my comments >> are hidden, I have to unfold many widgets. But it's not that bad. It >> seems like avoiding rebase works around some of these issues. > > I much prefer rietveld over github reviews, but I also much prefer the > integration between the bug tracker and github over the minimal > integration we had for rietveld. Thanks to all the people who made > that happen, and especially Brett for leading it. I am in favor of making this change :-) Victor From p.f.moore at gmail.com Tue Jul 18 16:33:22 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 18 Jul 2017 21:33:22 +0100 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: On 18 July 2017 at 20:59, Brett Cannon wrote: > I went ahead and clicked buttons. :) I set Python core as users and release > managers as admins (on top of Zach and me already being admins). Cool - when I log in now I have "python" as an option. I can't restart a build, but that's as expected - as admins, only RMs will be able to restart or cancel builds. It might be that adding the privilege "Projects -> Run Project Builds" (either to the "Users" role or to a specific new role linked with the core dev GH group) would give the ability to restart/cancel builds. But I haven't tested that. Paul From tjreedy at udel.edu Tue Jul 18 19:06:13 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 18 Jul 2017 19:06:13 -0400 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: On 7/18/2017 2:31 PM, Brett Cannon wrote: > Once again, glad the goals are panning out. :) Key thing has always been > to increase our bandwidth and part of that was always to push more on to > contributors so they can be more self-servicing. > > > * most contributors create backports (using cherry-pick) themself. > Before, this painful/error-prone task was usually done by a single > developer without any review, without pre-commit tests, etc. Backports affecting the same file should be done in the same order, with the same 'before' state. Real example: I merged PR A for file x.py and updated my clone to the result of the merge. I then prepared and merged PR B for the same file. Someone 'helpfully' prepared a backport of PR B, call it PR B3.6. It passed CI but was wrong. Fortunately, I checked the 'after' state of the file on a side-by-side diff. I prepared and merged PR A3.6, updated the 3.6 branck of my clone, and then prepared a new and correct backport of PR B. Correct backporting is most easily assured if backports are done immediately. I currently do so myself instead of requesting and waiting for a contributor to do so (who likely is not immediately available). Even better would be for the backport to happen automatically. > My wishlist that I don't think anyone is actively working on ATM is: > 2. Bot to backport PRs (which could also be automatically merged) So, to me, this is the priority item on the list. > 1. Bot to merge approved PRs (e.g. Rust's Homu) How is a bot going to re-write the commit message? Beside which, 'approve' does not necessarily mean 'commit now'. > 3. Automate Misc/ACKS (or do away with it and do something like > https://thanks.rust-lang.org/) Nice, but it is easy enough to ask the new contributor to do it ;-). > 4. Make test coverage reports consistent First, we need to make sure that the only difference in the before and after code is the diff shown on the PR files pages, so that the coverage difference is only due to the actual patch. From what I have seen, this does not seem true now. One way to make this happen would be to update the PR (or a copy thereof) to current repository, so that the only files affected by the tested PR are the ones intended and visible. Second, at least for IDLE, the .coveragerc file needs a few exclude lines added. I suspect that they would be compatible with the rest of the tests. (This could be checked with grep.) > 5. Automatically close stale PRs (e.g. not signing CLA, changes > requested but not being made, etc.) What does 'close' (without merging) mean? I would not want older (IDLE) PRs permanently gone in any sense just because I am busy reviewing other patches. I recently merged PR based on a patch uploaded to BPO 8 years ago. Not signing CLA is a special case. > 6. Bot to nudge core devs when they forget something (e.g. post-merge, > a comment if someone forgot to change the commit message or PR > number to have a "GH-" prefix) When possible, I would prefer to get reminders before the merge. -- Terry Jan Reedy From brett at python.org Tue Jul 18 19:01:39 2017 From: brett at python.org (Brett Cannon) Date: Tue, 18 Jul 2017 23:01:39 +0000 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: <20170718192126.88ABF1B10016@webabinitio.net> Message-ID: On Tue, 18 Jul 2017 at 12:54 Barry Warsaw wrote: > On Jul 18, 2017, at 15:21, R. David Murray wrote: > > > > I much prefer rietveld over github reviews, but I also much prefer the > > integration between the bug tracker and github over the minimal > > integration we had for rietveld. Thanks to all the people who made > > that happen, and especially Brett for leading it. > > Not that I?m suggesting anything should change, but just FWIW, I find > Gitlab to have a much better conversational review tool than Github. I > often find myself getting lost in GH reviews (on many projects), but GL > just organizes the conversation really well IMHO. > It's very obvious, Barry, that you're playing the long game of trying to line up GitLab as the next platform once we grow tired of GitHub and need to switch in a few years. I'm on to you. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Tue Jul 18 19:28:09 2017 From: brett at python.org (Brett Cannon) Date: Tue, 18 Jul 2017 23:28:09 +0000 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: On Tue, 18 Jul 2017 at 16:06 Terry Reedy wrote: > On 7/18/2017 2:31 PM, Brett Cannon wrote: > > > Once again, glad the goals are panning out. :) Key thing has always been > > to increase our bandwidth and part of that was always to push more on to > > contributors so they can be more self-servicing. > > > > > > * most contributors create backports (using cherry-pick) themself. > > Before, this painful/error-prone task was usually done by a single > > developer without any review, without pre-commit tests, etc. > > Backports affecting the same file should be done in the same order, with > the same 'before' state. > > Real example: I merged PR A for file x.py and updated my clone to the > result of the merge. I then prepared and merged PR B for the same file. > Someone 'helpfully' prepared a backport of PR B, call it PR B3.6. It > passed CI but was wrong. Fortunately, I checked the 'after' state of > the file on a side-by-side diff. I prepared and merged PR A3.6, updated > the 3.6 branck of my clone, and then prepared a new and correct backport > of PR B. > > Correct backporting is most easily assured if backports are done > immediately. I currently do so myself instead of requesting and waiting > for a contributor to do so (who likely is not immediately available). > Even better would be for the backport to happen automatically. > > > > My wishlist that I don't think anyone is actively working on ATM is: > Just so people know, I'm not going to reply to any comments about the wishlist since worrying about design details for something that doesn't even have someone motivated enough to work on it is I think too premature to worry about. I put this list here basically to see if something suddenly garnered someone's interest to implement or to see if there was an unexpected groundswell of interest to push it up the priority list. If any of these ideas to get someone behind them then the discussion will end up on the core-workflow mailing list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Tue Jul 18 19:34:02 2017 From: brett at python.org (Brett Cannon) Date: Tue, 18 Jul 2017 23:34:02 +0000 Subject: [python-committers] How do I kill an AppVeyor build? In-Reply-To: References: <9bec6d5e-1a2f-04c8-395d-e7769e9f54d4@python.org> Message-ID: On Tue, 18 Jul 2017 at 13:33 Paul Moore wrote: > On 18 July 2017 at 20:59, Brett Cannon wrote: > > I went ahead and clicked buttons. :) I set Python core as users and > release > > managers as admins (on top of Zach and me already being admins). > > Cool - when I log in now I have "python" as an option. I can't restart > a build, but that's as expected - as admins, only RMs will be able to > restart or cancel builds. > > It might be that adding the privilege "Projects -> Run Project Builds" > (either to the "Users" role or to a specific new role linked with the > core dev GH group) would give the ability to restart/cancel builds. > But I haven't tested that. > I had to delete the Python core team access, create a new type of role, and then re-add the Python team access (sorry to anyone who logged in already using that access, I think AppVeyor reset things), but I now have a role where we can tweak settings and I added the "run project builds" to the Super User role everyone has access through. -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Tue Jul 18 19:37:16 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 19 Jul 2017 01:37:16 +0200 Subject: [python-committers] Dismiss review if a PR is modified In-Reply-To: References: Message-ID: Oh. For backports, it's convenient to be able to merge without a review. I see many cores doing it and I like it. For master, I don't know. Sometimes a PR is merged too fast, sometiles nobody reviews a PR even if it's good. So for the master branch, the dev takes its own responsability to merge ;-) I only asked if it would be possible to dismiss an approval or mark the review as outdated if the change is modified afterwards, but it seems like GitHub doesn't offer many choices... The current behaviour is okish. It was just a minor whish. Victor Le 19 juil. 2017 1:13 AM, "Brett Cannon" a ?crit : On Tue, 18 Jul 2017 at 13:10 Victor Stinner wrote: > 2017-07-18 21:21 GMT+02:00 R. David Murray : > > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner < > victor.stinner at gmail.com> wrote: > >> I'm just not unconfortable with the fact that an approval is kept even > >> if the PR is modified after the review :-/ I would expect a list a > >> notice "changed modified after the review" or something like that. At > >> least, for my own reviews, to remind me to review again. > > > > This could be changed if we have consensus to do so. Github has a > > setting that will cause existing approvals to be "dismissed" if > > a new commit is pushed. > > > >> Compared to Rietveld, GitHub review tool is as "a good" (not much > >> better, not much worse). Sometimes, I'm lost in reviews: my comments > >> are hidden, I have to unfold many widgets. But it's not that bad. It > >> seems like avoiding rebase works around some of these issues. > > > > I much prefer rietveld over github reviews, but I also much prefer the > > integration between the bug tracker and github over the minimal > > integration we had for rietveld. Thanks to all the people who made > > that happen, and especially Brett for leading it. > > I am in favor of making this change :-) > Do realize that setting is part of requiring a review for pull requests: https://help.github.com/articles/enabling-required- reviews-for-pull-requests/. So in order to get this we would require all PRs, core dev or not, to receive an approving review from another core developer (I don't think an approving review from just anyone counts towards the minimum approval). There might be around this, but it will require some testing to make sure (see https://github.com/python/ core-workflow/issues/94#issuecomment-316224864). -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Tue Jul 18 19:13:41 2017 From: brett at python.org (Brett Cannon) Date: Tue, 18 Jul 2017 23:13:41 +0000 Subject: [python-committers] Dismiss review if a PR is modified In-Reply-To: References: Message-ID: On Tue, 18 Jul 2017 at 13:10 Victor Stinner wrote: > 2017-07-18 21:21 GMT+02:00 R. David Murray : > > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner < > victor.stinner at gmail.com> wrote: > >> I'm just not unconfortable with the fact that an approval is kept even > >> if the PR is modified after the review :-/ I would expect a list a > >> notice "changed modified after the review" or something like that. At > >> least, for my own reviews, to remind me to review again. > > > > This could be changed if we have consensus to do so. Github has a > > setting that will cause existing approvals to be "dismissed" if > > a new commit is pushed. > > > >> Compared to Rietveld, GitHub review tool is as "a good" (not much > >> better, not much worse). Sometimes, I'm lost in reviews: my comments > >> are hidden, I have to unfold many widgets. But it's not that bad. It > >> seems like avoiding rebase works around some of these issues. > > > > I much prefer rietveld over github reviews, but I also much prefer the > > integration between the bug tracker and github over the minimal > > integration we had for rietveld. Thanks to all the people who made > > that happen, and especially Brett for leading it. > > I am in favor of making this change :-) > Do realize that setting is part of requiring a review for pull requests: https://help.github.com/articles/enabling-required-reviews-for-pull-requests/. So in order to get this we would require all PRs, core dev or not, to receive an approving review from another core developer (I don't think an approving review from just anyone counts towards the minimum approval). There might be around this, but it will require some testing to make sure (see https://github.com/python/core-workflow/issues/94#issuecomment-316224864). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Tue Jul 18 19:53:25 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Tue, 18 Jul 2017 16:53:25 -0700 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: <20170718192126.88ABF1B10016@webabinitio.net> Message-ID: > > 2. Bot to backport PRs (which could also be automatically merged) > So, to me, this is the priority item on the list. I'm planning to work on the cherry-pick bot this during the core sprint in September. Unless someone beat me to it. Automatically close stale PRs (e.g. not signing CLA, changes > requested but not being made, etc.) This is also in my sprint plan, but only if I finish the cherry-pick bot :) Further discussion can be done here: https://github.com/python/core-workflow/issues/93 What does 'close' (without merging) mean? The PR will be closed. The branch containing the changeset will still be available in the contributor's fork of CPython. Unless they delete it too. On GitHub You can search for PRs that are closed but not merged by using the filters: is:pr is:closed is:unmerged A list of closed PRs that were not merged https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is% 3Apr%20is%3Aclosed%20is%3Aunmerged%20 I believe the reopening the PR straight-forward: click on the "Reopen pull request" button. Mariatta Wijaya On Tue, Jul 18, 2017 at 4:01 PM, Brett Cannon wrote: > > > On Tue, 18 Jul 2017 at 12:54 Barry Warsaw wrote: > >> On Jul 18, 2017, at 15:21, R. David Murray wrote: >> > >> > I much prefer rietveld over github reviews, but I also much prefer the >> > integration between the bug tracker and github over the minimal >> > integration we had for rietveld. Thanks to all the people who made >> > that happen, and especially Brett for leading it. >> >> Not that I?m suggesting anything should change, but just FWIW, I find >> Gitlab to have a much better conversational review tool than Github. I >> often find myself getting lost in GH reviews (on many projects), but GL >> just organizes the conversation really well IMHO. >> > > It's very obvious, Barry, that you're playing the long game of trying to > line up GitLab as the next platform once we grow tired of GitHub and need > to switch in a few years. I'm on to you. ;) > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Tue Jul 18 21:10:25 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 19 Jul 2017 11:10:25 +1000 Subject: [python-committers] Dismiss review if a PR is modified In-Reply-To: References: Message-ID: On 19 July 2017 at 09:37, Victor Stinner wrote: > Oh. > > For backports, it's convenient to be able to merge without a review. I see > many cores doing it and I like it. > > For master, I don't know. Sometimes a PR is merged too fast, sometiles > nobody reviews a PR even if it's good. So for the master branch, the dev > takes its own responsability to merge ;-) Right, "review required" settings can be useful, but they genuinely require a self-review option as an escape hatch in community projects, and GitHub doesn't currently offer that (it doesn't allow self-review at all, not even to mark your own PRs as still requiring further changes). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brett at python.org Tue Jul 18 21:29:14 2017 From: brett at python.org (Brett Cannon) Date: Wed, 19 Jul 2017 01:29:14 +0000 Subject: [python-committers] GitHub blog post on managing email notifications Message-ID: Thought people might be interested in this post (specifically the email header info) since I know some have said they have had issues in managing email notifications: https://github.com/blog/2399-managing-large-numbers-of-github-notifications -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Tue Jul 18 23:42:21 2017 From: guido at python.org (Guido van Rossum) Date: Tue, 18 Jul 2017 20:42:21 -0700 Subject: [python-committers] GitHub blog post on managing email notifications In-Reply-To: References: Message-ID: In a similar vein, I found the triangular workflow described here useful: https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows (TBH I don't follow the recipe exactly, but I do use upstream to point to the master repo, origin to point to my own fork on GitHub, and I have [remote] pushdefault = origin [push] default = current in my .git/config. Now every branch automatically gets pulled from upstream and pushed to origin, the perfect setup for submitting Pull Requests. On Tue, Jul 18, 2017 at 6:29 PM, Brett Cannon wrote: > Thought people might be interested in this post (specifically the email > header info) since I know some have said they have had issues in managing > email notifications: https://github.com/blog/2399-managing-large- > numbers-of-github-notifications > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Wed Jul 19 11:18:40 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Wed, 19 Jul 2017 11:18:40 -0400 Subject: [python-committers] Dismiss review if a PR is modified In-Reply-To: References: Message-ID: <20170719151840.DF2331B10001@webabinitio.net> On Tue, 18 Jul 2017 23:13:41 -0000, Brett Cannon wrote: > Do realize that setting is part of requiring a review for pull requests: > https://help.github.com/articles/enabling-required-reviews-for-pull-requests/. > So in order to get this we would require all PRs, core dev or not, to > receive an approving review from another core developer (I don't think an > approving review from just anyone counts towards the minimum approval). > There might be around this, but it will require some testing to make sure > (see > https://github.com/python/core-workflow/issues/94#issuecomment-316224864). Ah, I thought we were already doing that, but of course we aren't. Nevermind :) --David From barry at python.org Wed Jul 19 11:23:49 2017 From: barry at python.org (Barry Warsaw) Date: Wed, 19 Jul 2017 11:23:49 -0400 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: <20170718192126.88ABF1B10016@webabinitio.net> Message-ID: <20170719112349.14705b63@presto.wooz.org> On Jul 18, 2017, at 11:01 PM, Brett Cannon wrote: >It's very obvious, Barry, that you're playing the long game of trying to >line up GitLab as the next platform once we grow tired of GitHub and need >to switch in a few years. I'm on to you. ;) That, and bringing back the diamond operator for realz. -B -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From victor.stinner at gmail.com Wed Jul 19 11:31:48 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 19 Jul 2017 17:31:48 +0200 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: <20170719112349.14705b63@presto.wooz.org> References: <20170718192126.88ABF1B10016@webabinitio.net> <20170719112349.14705b63@presto.wooz.org> Message-ID: 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 at selma$ python3 Python 3.5.3 (default, May 10 2017, 15:05:55) >>> from __future__ import barry_as_FLUFL >>> 1 != 2 SyntaxError: invalid syntax >>> 1 <> 2 True Victor From brett at python.org Wed Jul 19 16:35:34 2017 From: brett at python.org (Brett Cannon) Date: Wed, 19 Jul 2017 20:35:34 +0000 Subject: [python-committers] Dismiss review if a PR is modified In-Reply-To: <20170719151840.DF2331B10001@webabinitio.net> References: <20170719151840.DF2331B10001@webabinitio.net> Message-ID: On Wed, 19 Jul 2017 at 08:18 R. David Murray wrote: > On Tue, 18 Jul 2017 23:13:41 -0000, Brett Cannon wrote: > > Do realize that setting is part of requiring a review for pull requests: > > > https://help.github.com/articles/enabling-required-reviews-for-pull-requests/ > . > > So in order to get this we would require all PRs, core dev or not, to > > receive an approving review from another core developer (I don't think an > > approving review from just anyone counts towards the minimum approval). > > There might be around this, but it will require some testing to make sure > > (see > > https://github.com/python/core-workflow/issues/94#issuecomment-316224864 > ). > > Ah, I thought we were already doing that, but of course we aren't. > Nevermind :) > I was planning on bringing this up in a year or so once everyone was comfortable with the workflow. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Wed Jul 19 21:51:46 2017 From: barry at python.org (Barry Warsaw) Date: Wed, 19 Jul 2017 21:51:46 -0400 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: <20170718192126.88ABF1B10016@webabinitio.net> <20170719112349.14705b63@presto.wooz.org> Message-ID: <0DB523C2-B99A-436D-A961-ADD5F1B4EC78@python.org> Ah, how deservedly superficial my title is: % python3 flufl.py File "flufl.py", line 3 1 <> 2 ^ SyntaxError: invalid syntax % cat flufl.py from __future__ import barry_as_FLUFL 1 <> 2 -Barry > On Jul 19, 2017, at 11:31, Victor Stinner wrote: > > 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 at selma$ python3 > Python 3.5.3 (default, May 10 2017, 15:05:55) >>>> from __future__ import barry_as_FLUFL >>>> 1 != 2 > SyntaxError: invalid syntax >>>> 1 <> 2 > True > > Victor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From rdmurray at bitdance.com Thu Jul 20 12:10:48 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Thu, 20 Jul 2017 12:10:48 -0400 Subject: [python-committers] I just gave Gareth Rees traige privileges on the tracker Message-ID: <20170720161048.AC0321B10001@webabinitio.net> 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 close himself. I've looked at some of his other tracker contributions as well, and they look to be of high quality. He hasn't made a huge number of contributions on the tracker, so I'm hoping this will encourage him to continue to be more active ;) I wasn't sure if a note like this would be considered noise on this list, but Victor told me in IRC that it helps him notice people, so I agreed I should post here. --David From tjreedy at udel.edu Thu Jul 20 13:29:17 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 20 Jul 2017 13:29:17 -0400 Subject: [python-committers] I just gave Gareth Rees traige privileges on the tracker In-Reply-To: <20170720161048.AC0321B10001@webabinitio.net> References: <20170720161048.AC0321B10001@webabinitio.net> Message-ID: <8696727e-3810-3948-b589-5fced8da6005@udel.edu> 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 close himself. > I've looked at some of his other tracker contributions as well, and they > look to be of high quality. He hasn't made a huge number of contributions > on the tracker, so I'm hoping this will encourage him to continue to be > more active ;) > > I wasn't sure if a note like this would be considered noise on this list, Not for me. > but Victor told me in IRC that it helps him notice people, so I agreed > I should post here. From senthil at uthcode.com Fri Jul 21 22:02:04 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 21 Jul 2017 19:02:04 -0700 Subject: [python-committers] Un-available till End of August -2017 Message-ID: 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 decided to rest a little from volunteering efforts. I just wanted to share this and I should perhaps inform active members earlier. I will become active towards the end of August 2017. Thank you, Senthil -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Sat Jul 22 12:31:49 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Sat, 22 Jul 2017 18:31:49 +0200 Subject: [python-committers] Un-available till End of August -2017 In-Reply-To: References: Message-ID: 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 decided > to rest a little from volunteering efforts. > > I just wanted to share this and I should perhaps inform active members > earlier. > > I will become active towards the end of August 2017. > > Thank you, > Senthil > > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Sun Jul 23 05:38:57 2017 From: antoine at python.org (Antoine Pitrou) Date: Sun, 23 Jul 2017 11:38:57 +0200 Subject: [python-committers] Travis-CI compiles twice Message-ID: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> Hi, I've noticed that Travis-CI (sometimes?) compiles CPython twice. Example in https://travis-ci.org/python/cpython/jobs/256552880 First compilation in the "./configure && make" step: https://travis-ci.org/python/cpython/jobs/256552880#L1103 Second compilation in "make buildbottest" step: https://travis-ci.org/python/cpython/jobs/256552880#L1622 This probably loses a minute or two. Regards Antoine. From brett at python.org Sun Jul 23 12:04:21 2017 From: brett at python.org (Brett Cannon) Date: Sun, 23 Jul 2017 16:04:21 +0000 Subject: [python-committers] Travis-CI compiles twice In-Reply-To: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> References: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> Message-ID: If you look at the exact commands it's configure, make, and then make regen-all clinic. My guess is that last command is touching files in such a way that the make bulidbottest is causing make to rebuild some files. On Sun, Jul 23, 2017, 02:39 Antoine Pitrou, wrote: > > Hi, > > I've noticed that Travis-CI (sometimes?) compiles CPython twice. > Example in https://travis-ci.org/python/cpython/jobs/256552880 > > First compilation in the "./configure && make" step: > https://travis-ci.org/python/cpython/jobs/256552880#L1103 > > Second compilation in "make buildbottest" step: > https://travis-ci.org/python/cpython/jobs/256552880#L1622 > > This probably loses a minute or two. > > Regards > > Antoine. > > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Mon Jul 24 03:00:07 2017 From: larry at hastings.org (Larry Hastings) Date: Mon, 24 Jul 2017 00:00:07 -0700 Subject: [python-committers] Python 3.5.4rc1 and 3.4.7rc1 slipping by a day, to July 24 2017 Message-ID: Release engineering for 3.5.4rc1 and 3.4.7rc1 took a lot longer than expected, because this is the first release using "blurb", and it turned out there was a lot of work left to do and a couple dark corners yet to stumble over. 3.5.4rc1 and 3.4.7rc1 will be released Monday, July 24, 2017. The release dates for 3.5.4 final and 3.4.7 final are not expected to change. Sorry about that, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From storchaka at gmail.com Mon Jul 24 03:37:24 2017 From: storchaka at gmail.com (Serhiy Storchaka) Date: Mon, 24 Jul 2017 10:37:24 +0300 Subject: [python-committers] Travis-CI compiles twice In-Reply-To: References: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> Message-ID: 23.07.17 19:04, Brett Cannon ????: > If you look at the exact commands it's configure, make, and then make > regen-all clinic. My guess is that last command is touching files in > such a way that the make bulidbottest is causing make to rebuild some files. `make regen-all` touches header files which are dependencies for all binaries. I suggest to run `make regen-all` before `make`. The more complex way is making all generating scripts generating new content in memory and don't touching the output files if their content matches the generated content. From larry at hastings.org Mon Jul 24 03:48:32 2017 From: larry at hastings.org (Larry Hastings) Date: Mon, 24 Jul 2017 00:48:32 -0700 Subject: [python-committers] My (positive) feedback on the new CPython workflow In-Reply-To: References: Message-ID: <68df5ac2-2dbd-0c0e-ad3b-8f69ea47b82a@hastings.org> On 07/18/2017 02:36 AM, Antoine Pitrou wrote: > 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. On 07/18/2017 03:24 AM, Victor Stinner wrote: > Thank you Larry Hastings, Brett Cannon and others who helped to write > and integrate blurb: no more Misc/NEWS conflict, it's just amazing :-) > We *all* wanted that for *years*! Thanks everybody! I'm glad it's been so well received. By coincidence, I only saw this thread today, /*after*/ spending hours working through the last blurb integration issues. But it's been a success. And I'm pleased to announce I'll be releasing 3.5.4rc1 and 3.4.7rc1 with blurb fully integrated! There were a few surprising ramifications of blurb--but nothing we can't live with. One nice side-effect of blurb: the formatting on Misc/NEWS, and therefore whatsnew/changelog.html, is somewhat improved. Every entry starts with a nice blue bpo-#### link, the section headers are 100% consistently spelled and in a consistent order, and we even have a shiny new "Security" section that goes at the top above "Core and Builtins". //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Mon Jul 24 04:55:44 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 24 Jul 2017 10:55:44 +0200 Subject: [python-committers] Travis-CI compiles twice In-Reply-To: References: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> Message-ID: IMHO everything is fine and we don't have to do anything ;-) Antoine: >I've noticed that Travis-CI (sometimes?) compiles CPython twice. "make regen-all" doesn't compiles Python: * it compiles Parser/pgen * it compiles Programs/_freeze_importlib * it runs many commands to regenerate generated files 2017-07-24 9:37 GMT+02:00 Serhiy Storchaka : > `make regen-all` touches header files which are dependencies for all > binaries. I suggest to run `make regen-all` before `make`. Zachary Ware explained me once that "make regen-all" should be run after "make", but I don't recall why :-) Travis CI makes sure that "make regen-all" doesn't modify generated files (or the build fails), so if we would run "make" a second time after "make regen-all", it would be supposed to do nothing. Victor From antoine at python.org Mon Jul 24 06:16:07 2017 From: antoine at python.org (Antoine Pitrou) Date: Mon, 24 Jul 2017 12:16:07 +0200 Subject: [python-committers] Travis-CI compiles twice In-Reply-To: References: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> Message-ID: <117a6d32-4de5-b8e6-4720-f7f5fe514c85@python.org> Le 24/07/2017 ? 10:55, Victor Stinner a ?crit : > IMHO everything is fine and we don't have to do anything ;-) What do you mean? The fact that all the CPython source code (including C extensions) is compiled twice looks suboptimal to me. We could probably win a minute or two on Travis-CI build times. Regards Antoine. From victor.stinner at gmail.com Mon Jul 24 06:27:41 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 24 Jul 2017 12:27:41 +0200 Subject: [python-committers] Travis-CI compiles twice In-Reply-To: <117a6d32-4de5-b8e6-4720-f7f5fe514c85@python.org> References: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> <117a6d32-4de5-b8e6-4720-f7f5fe514c85@python.org> Message-ID: I read again the read and I misunderstood it. I didn't notice that "make buildbottest" recompiles Python. Ok, I confirm the bug. I see two options: * move the "make regen-all" check *before* "make" * move the "make regen-all" check in a different Travis 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 : > > Le 24/07/2017 ? 10:55, Victor Stinner a ?crit : >> IMHO everything is fine and we don't have to do anything ;-) > > What do you mean? The fact that all the CPython source code (including > C extensions) is compiled twice looks suboptimal to me. We could > probably win a minute or two on Travis-CI build times. > > Regards > > Antoine. > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ From ncoghlan at gmail.com Mon Jul 24 09:48:17 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 24 Jul 2017 23:48:17 +1000 Subject: [python-committers] Travis-CI compiles twice In-Reply-To: References: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> Message-ID: On 24 July 2017 at 18:55, Victor Stinner wrote: > 2017-07-24 9:37 GMT+02:00 Serhiy Storchaka : >> `make regen-all` touches header files which are dependencies for all >> binaries. I suggest to run `make regen-all` before `make`. > > Zachary Ware explained me once that "make regen-all" should be run > after "make", but I don't recall why :-) Some of the generators (including Argument Clinic) are themselves written in Python, so building the checked in version first is the only way to be 100% sure you have a compatible version available. As Serhiy notes, the robust fix is to make sure the generators leave the file modification times unchanged if they don't actually change anything, either by working entirely in memory and only writing the result back out if it changed, or by generating out-of-place and then doing either a rename (if the result changed), or deleting the new one (if it is the same as the original). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From victor.stinner at gmail.com Mon Jul 24 11:37:12 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 24 Jul 2017 17:37:12 +0200 Subject: [python-committers] Travis-CI compiles twice In-Reply-To: References: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> Message-ID: 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 : > On 24 July 2017 at 18:55, Victor Stinner wrote: >> 2017-07-24 9:37 GMT+02:00 Serhiy Storchaka : >>> `make regen-all` touches header files which are dependencies for all >>> binaries. I suggest to run `make regen-all` before `make`. >> >> Zachary Ware explained me once that "make regen-all" should be run >> after "make", but I don't recall why :-) > > Some of the generators (including Argument Clinic) are themselves > written in Python, so building the checked in version first is the > only way to be 100% sure you have a compatible version available. > > As Serhiy notes, the robust fix is to make sure the generators leave > the file modification times unchanged if they don't actually change > anything, either by working entirely in memory and only writing the > result back out if it changed, or by generating out-of-place and then > doing either a rename (if the result changed), or deleting the new one > (if it is the same as the original). > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From zachary.ware+pydev at gmail.com Mon Jul 24 12:23:23 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Mon, 24 Jul 2017 11:23:23 -0500 Subject: [python-committers] Travis-CI compiles twice In-Reply-To: References: <6adba6c4-6695-bc17-68ca-19dfa6afa939@python.org> Message-ID: On Mon, Jul 24, 2017 at 3:55 AM, Victor Stinner wrote: > Zachary Ware explained me once that "make regen-all" should be run > after "make", but I don't recall why :-) The real kicker is `make clinic`, which fails unless done after `make all`. I'd be all in favor of fixing that (and adding `clinic` to `regen-all`), but if that turns into a bigger-than-expected project I also like Victor's idea of doing `make regen-all clinic` in a separate GCC job. -- Zach From larry at hastings.org Tue Jul 25 04:37:02 2017 From: larry at hastings.org (Larry Hastings) Date: Tue, 25 Jul 2017 01:37:02 -0700 Subject: [python-committers] RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available Message-ID: On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm relieved to announce the availability of Python 3.4.7rc1 and Python 3.5.4rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. Python 3.5.4 will be the final 3.5 release in "bug fix" mode. After 3.5.4 is released, Python 3.5 will also move into "security fixes mode". Both these releases are "release candidates". They should not be considered the final releases, although the final releases should contain only minor differences. Python users are encouraged to test with these releases and report any problems they encounter. You can find Python 3.4.7rc1 here: https://www.python.org/downloads/release/python-347rc1/ And you can find Python 3.5.4rc1 here: https://www.python.org/downloads/release/python-354rc1/ Python 3.4.7 final and Python 3.5.4 final are both scheduled for release on August 6th, 2017. Happy Pythoning, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From doko at ubuntu.com Tue Jul 25 06:23:08 2017 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 25 Jul 2017 12:23:08 +0200 Subject: [python-committers] RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available In-Reply-To: References: Message-ID: On 25.07.2017 10:37, Larry Hastings wrote: > And you can find Python 3.5.4rc1 here: > > https://www.python.org/downloads/release/python-354rc1/ > > > Python 3.4.7 final and Python 3.5.4 final are both scheduled for release on > August 6th, 2017. the build of the documentation fails with at least the 3.5.4rc1. It adds a new build dependency (blurb), which is inconvenient to build on stable environments, or when pip is not available. Please could you consider including the blurb module itself in python for the stable branches? The build of the docs then fails with: make -C Doc html make[1]: Entering directory '/home/packages/python/3.5/python3.5-3.5.4~rc1/Doc' mkdir -p build PYTHONPATH=/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb python3 -m blurb merge -f build/NEWS Traceback (most recent call last): File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.5/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py", line 1602, in main() File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py", line 1562, in main sys.exit(fn(*filtered_args, **kwargs)) File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py", line 970, in merge versions = glob_versions() File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py", line 284, in glob_versions with pushd("Misc/NEWS.d"): File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py", line 205, in __enter__ os.chdir(self.path) FileNotFoundError: [Errno 2] No such file or directory: 'Misc/NEWS.d' Makefile:42: recipe for target 'build' failed there is no Doc/Misc/NEWS.d directory (neither a Misc/NEWS.d directory) From victor.stinner at gmail.com Tue Jul 25 06:50:30 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Tue, 25 Jul 2017 12:50:30 +0200 Subject: [python-committers] RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available In-Reply-To: References: Message-ID: 2017-07-25 12:23 GMT+02:00 Matthias Klose : > the build of the documentation fails with at least the 3.5.4rc1. It adds a new > build dependency (blurb), which is inconvenient to build on stable environments, > or when pip is not available. Please could you consider including the blurb > module itself in python for the stable branches? Sorry, I didn't look yet how blurb generates the documentation, but if blurb is deterministic and only generates files: would it be possible to include generated files in tarballs to prevent completely the need of blurb to build Python from a release tarball? Victor From nad at python.org Tue Jul 25 08:48:01 2017 From: nad at python.org (Ned Deily) Date: Tue, 25 Jul 2017 08:48:01 -0400 Subject: [python-committers] RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available In-Reply-To: References: Message-ID: On Jul 25, 2017, at 06:50, Victor Stinner wrote: > 2017-07-25 12:23 GMT+02:00 Matthias Klose : >> the build of the documentation fails with at least the 3.5.4rc1. It adds a new >> build dependency (blurb), which is inconvenient to build on stable environments, >> or when pip is not available. Please could you consider including the blurb >> module itself in python for the stable branches? > > Sorry, I didn't look yet how blurb generates the documentation, but if > blurb is deterministic and only generates files: would it be possible > to include generated files in tarballs to prevent completely the need > of blurb to build Python from a release tarball? Matthias has discovered a bug in the new process. The tarball does indeed already have a generated Misc/NEWS. The quandry is that the blurb generation step is needed when building the docs directly from the Git repo, including the daily website builds, but it should not be performed when building the Docs from a release tarball. Please open an issue for this on the tracker and mark it as "release blocker" so it can get sorted out before the final releases. -- Ned Deily nad at python.org -- [] From victor.stinner at gmail.com Tue Jul 25 20:30:55 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 26 Jul 2017 02:30:55 +0200 Subject: [python-committers] AppVeyor was unable to build non-mergeable pull request Message-ID: Hi, It's the second time today that I get this error on a PR: "continuous-integration/appveyor/pr ? AppVeyor was unable to build non-mergeable pull request" With such failure, it's not possible to merge a PR. The error just occurred on a 2.7 change which is a single commit on top of the update to date 2.7 head: https://github.com/python/cpython/pull/2877 For the other PR, I used the workaround found at: http://help.appveyor.com/discussions/problems/4830-stuck-on-appveyor-was-unable-to-build-non-mergeable => close the PR, reopen the PR It works around the issue, but it 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 Date: Wed Jul 26 02:20:55 2017 +0200 bpo-30778: Skip test_bsddb3 on Windows XP commit 0666d0e50432e3b0109db96b8e48fb6c496bd49c <= upstream HEAD Author: Aditya Hase Date: Wed Jul 26 02:29:52 2017 +0530 bpo-30304: Improve TestCase.assertMultiLineEqual docs (GH-2847) Mention that TestCase.assertMultiLineEqual method is used by default when comparing Unicode string when comparing Unicode strings with assertEqual. (...) Victor From victor.stinner at gmail.com Tue Jul 25 22:25:50 2017 From: victor.stinner at gmail.com (Victor Stinner) Date: Wed, 26 Jul 2017 04:25:50 +0200 Subject: [python-committers] AppVeyor was unable to build non-mergeable pull request In-Reply-To: References: Message-ID: 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 From brett at python.org Tue Jul 25 22:22:25 2017 From: brett at python.org (Brett Cannon) Date: Wed, 26 Jul 2017 02:22:25 +0000 Subject: [python-committers] AppVeyor was unable to build non-mergeable pull request In-Reply-To: References: Message-ID: So are you requesting we stop building on AppVeyor? On Tue, Jul 25, 2017, 17:31 Victor Stinner, wrote: > Hi, > > It's the second time today that I get this error on a PR: > > "continuous-integration/appveyor/pr ? AppVeyor was unable to build > non-mergeable pull request" > > With such failure, it's not possible to merge a PR. > > The error just occurred on a 2.7 change which is a single commit on > top of the update to date 2.7 head: > https://github.com/python/cpython/pull/2877 > > For the other PR, I used the workaround found at: > > http://help.appveyor.com/discussions/problems/4830-stuck-on-appveyor-was-unable-to-build-non-mergeable > > => close the PR, reopen the PR > > It works around the issue, but it 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 > Date: Wed Jul 26 02:20:55 2017 +0200 > > bpo-30778: Skip test_bsddb3 on Windows XP > > commit 0666d0e50432e3b0109db96b8e48fb6c496bd49c <= upstream HEAD > Author: Aditya Hase > Date: Wed Jul 26 02:29:52 2017 +0530 > > bpo-30304: Improve TestCase.assertMultiLineEqual docs (GH-2847) > > Mention that TestCase.assertMultiLineEqual method is used by > default when comparing Unicode string when comparing Unicode strings > with assertEqual. > > (...) > > Victor > _______________________________________________ > python-committers mailing list > python-committers at python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Tue Jul 25 22:59:52 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 25 Jul 2017 22:59:52 -0400 Subject: [python-committers] AppVeyor was unable to build non-mergeable pull request In-Reply-To: References: Message-ID: <8ca95509-3094-c100-9c83-43fbc343bc07@udel.edu> On 7/25/2017 10:22 PM, Brett Cannon wrote: > So are you requesting we stop building on AppVeyor? Since it runs gui tests, and Travis does not, it is very useful. For the last week, it has mostly always run. > On Tue, Jul 25, 2017, 17:31 Victor Stinner, > wrote: > > Hi, > > It's the second time today that I get this error on a PR: > > "continuous-integration/appveyor/pr ? AppVeyor was unable to build > non-mergeable pull request" I have seen this too, but seldom. > With such failure, it's not possible to merge a PR. I believe I was allowed to, but when the new tests are gui tests, it is definitely questionable. > The error just occurred on a 2.7 change which is a single commit on > top of the update to date 2.7 head: > https://github.com/python/cpython/pull/2877 > For the other PR, I used the workaround found at: > http://help.appveyor.com/discussions/problems/4830-stuck-on-appveyor-was-unable-to-build-non-mergeable > > => close the PR, reopen the PR Thanks for the information. > It works around the issue, but it spams Travis CI which has to abort > running jobs, and then restarts new jobs from scratch. I quit worrying about that. Terry Jan Reedy From brett at python.org Wed Jul 26 00:39:21 2017 From: brett at python.org (Brett Cannon) Date: Wed, 26 Jul 2017 04:39:21 +0000 Subject: [python-committers] AppVeyor was unable to build non-mergeable pull request In-Reply-To: References: Message-ID: On Tue, Jul 25, 2017, 19:26 Victor Stinner, wrote: > 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? > I don't see how it could be our fault or something we can control for. > Victor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Fri Jul 28 15:42:21 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 28 Jul 2017 20:42:21 +0100 Subject: [python-committers] New workflow - some questions Message-ID: I'm just looking at doing some work for the first time under the new workflow. Most things look fine - I'm familiar with git/github, so there's nothing startling in there, but I do have a few small questions: 1. Section 32.2 in the Git bootcamp section - is there any reason to use git at github URLs for the clones? I normally always use https://github.com URLs, as they work with my proxy at work. 2. Section 32.10, I generally use "Compare and create pull request" from my clone's github page, as that seems simpler. Is there any reason for starting from the cpython repo - the process working that way (which I wasn't even aware of!) seems more complex. I can't see that it matters much, but I wouldn't want to mess up a PR if there *is* a difference in the results. 3. The new blurb tool - I presume I'll need to set that up somewhere/somehow, and use it to create a news entry. But I can't find any docs on it at all :-( There may be other stuff - I've been watching the core-workflow list, and it feels like there's some awfully complex stuff being discussed. But so far it looks pretty straightforward and "as expected" - which is a credit to Brett and the others who've set all this up! Thanks, Paul From mariatta.wijaya at gmail.com Fri Jul 28 18:30:56 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Fri, 28 Jul 2017 15:30:56 -0700 Subject: [python-committers] New workflow - some questions In-Reply-To: References: Message-ID: > > 1. Section 32.2 in the Git bootcamp section - is there any reason to > use git at github URLs for the clones? I normally always use > https://github.com URLs, as they work with my proxy at work. I don't have any explanation other than Git bootcamp was initially written based on my personal setup. I cloned CPython using SSH, and that's what I wrote in the devguide :) You can use HTTPS if that works for you. Perhaps someone else can explain better the difference between cloning via HTTPS and SSH. I generally use "Compare and create pull request" > from my clone's github page, as that seems simpler. Note that the link is only visible within 30 minutes (or so) after you pushed your branch to remote. If you did not create the PR immediately after pushing, the link disappears. In this case, the instructions in 32.10 will help (maybe?). Can we assume that people will create their PR immediately? Maybe an improvement is to mention the "Compare and create pull request", and to do this immediately after pushing the branch. side-topic: Does anyone have some sort of script/git alias/program/whatchamacallit that will open the PR page once we push to remote? (similar to what cherry_picker does) That could be a time saver :) 3. The new blurb tool - I presume I'll need to set that up > somewhere/somehow, and use it to create a news entry. But I can't find > any docs on it at all :-( pip install blurb Some write-up here: https://devguide.python.org/committing/#what-s-new- and-news-entries blurb readme: https://github.com/python/core-workflow/blob/ master/blurb/README.rst Mariatta Wijaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From songofacandy at gmail.com Fri Jul 28 23:39:32 2017 From: songofacandy at gmail.com (INADA Naoki) Date: Sat, 29 Jul 2017 12:39:32 +0900 Subject: [python-committers] New workflow - some questions In-Reply-To: References: Message-ID: On Sat, Jul 29, 2017 at 7:30 AM, Mariatta Wijaya wrote: >> 1. Section 32.2 in the Git bootcamp section - is there any reason to >> use git at github URLs for the clones? I normally always use >> https://github.com URLs, as they work with my proxy at work. > > > I don't have any explanation other than Git bootcamp was initially written > based on my personal setup. > I cloned CPython using SSH, and that's what I wrote in the devguide :) > You can use HTTPS if that works for you. > Perhaps someone else can explain better the difference between cloning via > HTTPS and SSH. > I usually uses https for "read-only" remote. Sometimes, even I have commit rights, I use pull request from personal fork and I don't want to push directly. Of course, I can use https to push. But it requires some additional steps. So it prevent accidental push to "origin". I think there are no downside to use HTTPS for "read only" remotes. > >> I generally use "Compare and create pull request" >> from my clone's github page, as that seems simpler. > > > Note that the link is only visible within 30 minutes (or so) after you > pushed your branch to remote. > If you did not create the PR immediately after pushing, the link disappears. > In this case, the instructions in 32.10 will help (maybe?). > Can we assume that people will create their PR immediately? > Maybe an improvement is to mention the "Compare and create pull request", > and to do this immediately after pushing the branch. > > side-topic: Does anyone have some sort of script/git > alias/program/whatchamacallit that will open the PR page once we push to > remote? (similar to what cherry_picker does) That could be a time saver :) > I use Github's "hub" CLI. https://github.com/github/hub "hub pull-request" can be used to create pull request from terminal. "hub browse" can be used to open browser for current branch. Regards, From p.f.moore at gmail.com Sat Jul 29 04:40:25 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Jul 2017 09:40:25 +0100 Subject: [python-committers] New workflow - some questions In-Reply-To: References: Message-ID: 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 at github URLs for the clones? I normally always use >> https://github.com URLs, as they work with my proxy at work. > > > I don't have any explanation other than Git bootcamp was initially written > based on my personal setup. > I cloned CPython using SSH, and that's what I wrote in the devguide :) > You can use HTTPS if that works for you. > Perhaps someone else can explain better the difference between cloning via > HTTPS and SSH. Thanks for the clarification - I doubt it matters much whether you use https or git in practice. I've found https better for me because it's more proxy friendly. I don't really know the differences because I've never used git. >> I generally use "Compare and create pull request" >> from my clone's github page, as that seems simpler. > > Note that the link is only visible within 30 minutes (or so) after you > pushed your branch to remote. Ah - I didn't know that, When working on pip, I normally push and create a PR in quick succession. > If you did not create the PR immediately after pushing, the link disappears. > In this case, the instructions in 32.10 will help (maybe?). They will - a lot. Thanks. > Can we assume that people will create their PR immediately? Definitely not, in general. > Maybe an improvement is to mention the "Compare and create pull request", > and to do this immediately after pushing the branch. It might be worth suggesting it as an option, simply so that if a contributor sees the button, they know it's just an alternative approach and it's OK to use. I'll see if I can think of some wording that would help here. > side-topic: Does anyone have some sort of script/git > alias/program/whatchamacallit that will open the PR page once we push to > remote? (similar to what cherry_picker does) That could be a time saver :) I don't - that's the sort of thing I just do manually. (I work on multiple machines, so I'm heavily reliant on minimising the amount of custom scripts and/or setup needed to work on a project. For me, a simple, easily remembered workflow with minimal dependencies on specialised tools works best.) >> 3. The new blurb tool - I presume I'll need to set that up >> somewhere/somehow, and use it to create a news entry. But I can't find >> any docs on it at all :-( > > pip install blurb Doh. I think I recall some discussion about using virtualenvs and maybe that made me think something complex was needed. My mistake. > Some write-up here: > https://devguide.python.org/committing/#what-s-new-and-news-entries Again doh - I don't know how I missed that, thanks. > blurb readme: > https://github.com/python/core-workflow/blob/master/blurb/README.rst Paul From ncoghlan at gmail.com Sat Jul 29 09:13:07 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 29 Jul 2017 23:13:07 +1000 Subject: [python-committers] New workflow - some questions In-Reply-To: References: Message-ID: On 29 July 2017 at 18:40, 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 at github URLs for the clones? I normally always use >>> https://github.com URLs, as they work with my proxy at work. >> >> >> I don't have any explanation other than Git bootcamp was initially written >> based on my personal setup. >> I cloned CPython using SSH, and that's what I wrote in the devguide :) >> You can use HTTPS if that works for you. >> Perhaps someone else can explain better the difference between cloning via >> HTTPS and SSH. > > Thanks for the clarification - I doubt it matters much whether you use > https or git in practice. I've found https better for me because it's > more proxy friendly. I don't really know the differences because I've > never used git. To be honest, the read-only=HTTPS & read/write=SSH split is likely a Linux+macOS-ism, where we can do "ssh-add" once, and then never have to worry about explicitly authenticating again until we reboot our client machine. As Inada-san notes, the password prompt when accidentally doing a direct push to a HTTPS clone then serves as a reminder that you probably meant to push to a different remote that's set up for read/write access over SSH. There's no functional difference on the server side though - it's strictly about how the git client authenticates your identity with the server. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From p.f.moore at gmail.com Sat Jul 29 09:30:39 2017 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 29 Jul 2017 14:30:39 +0100 Subject: [python-committers] New workflow - some questions In-Reply-To: References: Message-ID: On 29 July 2017 at 14:13, Nick Coghlan wrote: > To be honest, the read-only=HTTPS & read/write=SSH split is likely a > Linux+macOS-ism, where we can do "ssh-add" once, and then never have > to worry about explicitly authenticating again until we reboot our > client machine. As Inada-san notes, the password prompt when > accidentally doing a direct push to a HTTPS clone then serves as a > reminder that you probably meant to push to a different remote that's > set up for read/write access over SSH. > > There's no functional difference on the server side though - it's > strictly about how the git client authenticates your identity with the > server. On Windows you can use the git credential manager to store credentials in the OS cert store, and then https is passwordless for push. Paul From tjreedy at udel.edu Sat Jul 29 12:02:05 2017 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 29 Jul 2017 12:02:05 -0400 Subject: [python-committers] New workflow - some questions In-Reply-To: References: Message-ID: <5153e40a-cfe1-afea-e492-995a8d9a0cea@udel.edu> 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 at github URLs for the clones? I normally always use >>> https://github.com URLs, as they work with my proxy at work. As I understand it, https uses stored login credentials, git@ uses ssh key. I use https always. >>> I generally use "Compare and create pull request" >>> from my clone's github page, as that seems simpler. I often use my fork's 'branches' page, which always has 'pull request' buttons, and just leave it open. >> side-topic: Does anyone have some sort of script/git >> alias/program/whatchamacallit that will open the PR page once we push to >> remote? (similar to what cherry_picker does) That could be a time saver :) If I type 'cp' in my browser url bar, github.com/python/cpython is at the top of my history list. For 'te', github.com/terryjreedy is at the top. They were initially further down, but present after a few visits. The first rose first, as 'cp' is a very uncommon pair. Terry From brett at python.org Mon Jul 31 12:50:28 2017 From: brett at python.org (Brett Cannon) Date: Mon, 31 Jul 2017 16:50:28 +0000 Subject: [python-committers] New workflow - some questions In-Reply-To: <5153e40a-cfe1-afea-e492-995a8d9a0cea@udel.edu> References: <5153e40a-cfe1-afea-e492-995a8d9a0cea@udel.edu> Message-ID: On Sat, 29 Jul 2017 at 09:05 Terry Reedy wrote: > 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 at github URLs for the clones? I normally always use > >>> https://github.com URLs, as they work with my proxy at work. > > As I understand it, https uses stored login credentials, git@ uses ssh > key. I use https always. > GitHub has a page dedicated on helping you choose the approach: https://help.github.com/articles/which-remote-url-should-i-use/. For me personally, if I'm on Linux (and this includes WSL!) I use SSH, otherwise I use HTTPS with a credential helper (or put another way: if I can use a credential helper I use HTTPS, else use SSH). -------------- next part -------------- An HTML attachment was scrubbed... URL: