Hi, 2017-07-18 11:36 GMT+02:00 Antoine Pitrou <anto...@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 _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
