python-committers July 2017

python-committers@python.org

20 participants
24 discussions

Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California

by Lukasz Langa

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

3 years, 8 months

Please edit the commit message when merge a PR

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

3 years, 9 months

New workflow - some questions

by Paul Moore

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

3 years, 9 months

AppVeyor was unable to build non-mergeable pull request

by Victor Stinner

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-un… => 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 <victor.stinner(a)gmail.com> Date: Wed Jul 26 02:20:55 2017 +0200 bpo-30778: Skip test_bsddb3 on Windows XP commit 0666d0e50432e3b0109db96b8e48fb6c496bd49c <= upstream HEAD Author: Aditya Hase <aditya(a)adityahase.com> 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

3 years, 9 months

RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available

by Larry Hastings

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/

3 years, 9 months

Travis-CI compiles twice

by Antoine Pitrou

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.

3 years, 9 months

My (positive) feedback on the new CPython workflow

by Victor Stinner

Hi, 2017-07-18 11:36 GMT+02:00 Antoine Pitrou <antoine(a)python.org>: > 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

3 years, 9 months

Python 3.5.4rc1 and 3.4.7rc1 slipping by a day, to July 24 2017

by Larry Hastings

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/

3 years, 9 months

Un-available till End of August -2017

by Senthil Kumaran

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

3 years, 9 months

I just gave Gareth Rees traige privileges on the tracker

by R. David Murray

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

3 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers July 2017