[Distutils] Implementing large changes in small increments (was: Getting more momentum for pip)

[Nick Coghlan]

On 6 March 2015 at 08:00, Ben Finney <ben+python at benfinney.id.au> wrote:
> Donald Stufft <donald at stufft.io> writes:
>
>> Sadly with how the code in pip is written, sometimes it’s just not
>> reasonable to make small PRs because things are not well factored and
>> changing things requires touching a lot of different areas.
>
> I've seen a number of other projects enforce “small revisions only,
> otherwise your change gets accepted”. If actually enforced, it is a
> highly successful way to get meaningful review of changes, and does not
> appear to limit the scope of the eventual change.
>
> What does end up happening in such projects (e.g., Linux) is the
> community learns how to – and teaches newcomers how to – implement large
> changes as smaller refactorings, each of which results in a working
> system.

This is:

a) a really good idea; and
b) really painful without good tooling support

Linux does it via emailed patchbombs, as do a lot of other open source
projects which don't have a separate code review tool. That works if
your contributors are used to *consuming* patches that way, but
inapplicable to projects used to web based reviews.

CPython uses the Reitveld instance integrated with bugs.python.org,
and has the same problem as pip: incremental changes are a pain to
publish, review, and merge, so we review and accept monolithic patches
instead (cf the problem statement in
https://www.python.org/dev/peps/pep-0462/)

While the main UI is very busy, I've actually quite liked my own
experience with Gerrit for http://gerrit.beaker-project.org/ (I was
the dev lead for Red Hat's Beaker hardware integration testing system
from Oct 2012 until mid 2014, and the product owner until a couple of
weeks ago). I've never used Gerrit in the OpenStack context though, so
I don't know if Donald dislikes Gerrit in its own right, or just the
way OpenStack uses it.

That means one option potentially worth exploring might be
http://gerrithub.io/. I haven't used GerritHub yet myself, but I'm
pretty sure it lets you mix & match between GitHub PRs for simple
changes and GerritHub reviews for more complex ones.

The Beaker workflow  is an example of vanilla Gerrit usage, rather
than using OpenStack's custom fork:
https://beaker-project.org/dev/guide/writing-a-patch.html#submitting-your-patch

http://gerrit.beaker-project.org/#/c/4025 is an example of a fairly
deep patch stack, where each patch can be reviewed independently, but
later patches won't be merged until after earlier ones have been
submitted. (Rebasing support is also baked directly into the tool)

Regards,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia