My feedback on the Python workflow
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
participants (1)
-
Victor Stinner