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