[core-workflow] Software Factory

[Donald Stufft]

> On Nov 23, 2015, at 7:50 AM, Victor Stinner <victor.stinner at gmail.com> wrote:
> 
> 2015-11-23 13:42 GMT+01:00 Donald Stufft <donald at stufft.io>:
>> TBH I really really hate Gerrit. The workflow it enables is fine, but Gerrit itself is horrible.
> 
> This kind of feedback is not really helpful :-/ Can you please
> elaborate? What's wrong with Gerrit?
> 
> Gerrit is used on OpenStack which is a very large project: 4,689
> developers, 200 commits per day, etc. Some statistics at:
> http://activity.openstack.org/dash/browser/
> 
> Victor


I know, I was at one point, core on at least one Openstack project (I might have been on others, I forget) and I’ve been interacting with Openstack and their Gerrit since ~2011 or so.

The UI of Gerrit is atrocious. It’s confusing and ugly. Once you spend the time to grok how it works it can be effective, but that requires sitting down and figuring out how it actually works first and one of the goals of the new workflows is lowering barriers to contributors, not shifting the learning curve from uploading patches to fighting with Gerrit.

Often times when Openstack asks me to comment on something, I read it on Gerrit and then communicate my review via IRC because I find that massively less painful than fighting with Gerrit. I also rarely ever make changes via Gerrit anymore (ever since I stopped being paid for it) and I just tell someone else what change they should make and let them deal with Gerrit.[1]

Openstack is a bit different because almost every contributor is being paid to work on it. That means that they don’t have to worry (as much) about on boarding pain because those people are being paid to sit there and learn how to use the tooling. CPython on the other hand is almost entirely worked on by volunteers so on boarding pain is very likely to just have people drop off instead of trying to learn the toolchain.

It wouldn’t be hard to get most of the benefit of the Gerrit workflow in either Gitlab or Github. For Github there’s an external project called Reviewable which gives you a review interface similar to Gerrit (which I hate but some people like it I guess). Both of them support running CI on a branch (Though neither have the “press merge button, but don’t merge until tests run again thing).

I don’t know specifics of Gitlab very well, but for Github it’s trivial to get access to the changes of a PR as well. You just add a single line to your .git/config and then you can check PRs out as their own branches.

[1] This works largely because I rarely need to make changes myself. They come to me with a packaging problem and I tell them what they need to change to fix it.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 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: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151123/8c7f4b8c/attachment.sig>