[core-workflow] My feedback on the Python workflow

[Victor Stinner]

Hi,

Brett contacted me to ask me to try the new workflow to develop
Python. I'm sorry, I completly missed the whole discussiong. I would
like to share my feedback on the Python workflow and the OpenStack
worklow. I will start by listing random issues with the current Python
workflow, even if you all probably know them (I hope).

I'm contributing to CPython since more than 5 years. Since I started
to work on OpenStack, I realized that how the CPython workflow is
outdated. Attached .patch files to a bug tracker was cool 10 years
ago, but today using merges is preferred. Issues with .patch files:

* it's hard to "rebase" a patch: even if the patch contains the base
revision, it's not convenient to rebase a patch (it's hard to rebasing
a branch)
* it's very hard to work on a patch serie, so nobody does that. As a
consequence, patches can be very long and hard to review

The integration between Round up (bug tracker) and Rietveld (review)
is good, but incomplete. Adding comments to Rietveld doesn't copy them
to the bug tracker. Unsubscribe from a bug doesn't unsubscribe from
the the review, which can be very annoying for review staying a month
or much longer (lot of spam).

Because of the Misc/NEWS file, it's never possible to simply apply
bindly a patch. It's common that I modify a patch after a review, to
fix minor nits, like coding style. I don't want to annoy contributors
with such minor details at the *end* of the review (when I missed them
before).

Tests are only run after the commit, it's common to break *all*
buildbots because of a stupid mistake in a patch. The common issue is
that modifying the module xxx requires to run test_xxx, but test_yyy
fails and the review and the commiter forgot to run all tests. Another
common issue is that a change breaks all Windows buildbots because of
an obvious compilation isssue, but too few core reviewers test and
work on Windows.

I don't think that it would be possible to run the *full* test suite
on pre-commit, but it would be a nice enhancement to start with a
small subset of tests on buildbots known to be very stable (ex: only
one Linux buildbot). And later slowly add more and more tests, and
more and more buildbots.

It's also annoying that Mercurial has no committer field, and so that
the original author is not tracked in commit metadata. All core
developers try to put the author in the commit message, but it's not
counted in statistics. It would motivate to give more credits to
contributors to "show" their name in commits. The commiter is also a
very important information, it's the responsible of regressions,
he/she has to break regressions and all side effects of the change.
(Even if it's common and totally ok if someone else fixes these
issues.)

Victor