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

[Donald Stufft]

> On Mar 6, 2015, at 8:55 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> 
> On 2015-03-06 21:37:31 +1000 (+1000), Nick Coghlan wrote:
> [...]
>> 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.
> [...]
> 
> Having talked with him about it regularly, I gather that he (and
> others) dislike the Gerrit/LKML "rebase, revise and refine your
> patch" workflow, instead preferring a Github-like "incrementally
> build on your pull request with new commits" workflow... though
> presumably he can explain it in better detail.
> 
> In my experience it comes down to a trade-off where the Github model
> is easier on patch submitters because they can just keep piling
> fixes for their pull request on top if it until the corresponding
> topic branch is suitable to merge, while the Gerrit model is easier
> on reviewers because they're reviewing a patch in context rather
> than a topic branch.
> 
>> The Beaker workflow  is an example of vanilla Gerrit usage, rather
>> than using OpenStack's custom fork:
> [...]
> 
> OpenStack hasn't been running a fork of Gerrit since upgrading to
> 2.8 back in April 2014 (modulo a few simple backports from 2.9), and
> has plans to upgrade to 2.9 next month or the month after. That's
> not to say that there isn't a bunch of additional tooling and
> automation built up around it (the Zuul CI system in particular) but
> aside from some minimal theming and including a little Javascript to
> tie outside data sources into the interface it's just plain Gerrit.
> --
> Jeremy Stanley
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

In general I’m fine with Gerrit (or Gerrit like systems).

I think Gerrit has a crappy looking interface, and I think that the interface
is harder to use than GitHub but the process itself doesn’t bother me much. I
do think that it would be better if it would review whole PRs instead of
individual commits (and if you want to squash them, the tool should do a squash
merge).

I don’t think that pip’s problems are ones that would be solved by switching to
a different code review tool. GitHub functions well for that task, we don’t
require multiple core reviewers to agree, only one, so the merge button is
functionally equivalent to a +1 button and then having a machine later do the
merge. Our velocity isn’t near high enough to where we need separate check and
merge gating or anything like that. I would be against moving away from GitHub
for PRs without a really compelling reason, GitHub PRs are easy to use, and it’s
popular. We reduce the barrier to entry to contributing by making our process the
same as every other project on GitHub’s.

A better test suite and a more comprehensive CI system is where most of our tooling
problems are.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150306/9e130d04/attachment.sig>