2017-07-18 11:36 GMT+02:00 Antoine Pitrou <email@example.com>:
> 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
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
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:
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
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
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
* 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
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*!
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:
I think that wishlist would get us as automated as reasonably possible while reminding people when the manual parts are accidentally done wrong.