> On Nov 23, 2015, at 7:50 AM, Victor Stinner <victor.stin...@gmail.com> wrote:
> 
> 2015-11-23 13:42 GMT+01:00 Donald Stufft <don...@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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Reply via email to