[ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?

[Nils Carlson]

On 06/11/2018 03:18 PM, Adam Spiers wrote:
> Nils Carlson <pyssling at ludd.ltu.se> wrote:
>> On 2018-06-07 08:58, Kristoffer Grönlund wrote:
>>> I'll confess that I have no experience with Gerrit or the Github 
>>> required reviews, and I don't really know how they differ. :) 
>>
>> Adding some info as these are things I know something about.
>> Gitlab & Github are very similar, but I much prefer Gitlab after 
>> having used both.
>> For open-source projects Gitlab gives you all features, including 
>> things like "approvers" for merge-requests. They have a nice 
>> permission model which allows only some users to approve merge 
>> requests and to set a minimum number of approvers. 
> 
> That's really nice, and a limitation of GitHub I have already documented:
> 
>     https://github.com/isaacs/github/issues/779
> 
>> The fundamental unit of review in Gitlab is the merge-request, 
>> requesting that a branch be merged into another. This works very well 
>> in practice. You can configure a regex for branch names and only allow 
>> users to push to branches with a prefix like "contributions/", making 
>> all other branches "protected", i.e. prevent direct pushes.
>> The code-review is good, but could be better. Every time you update 
>> the branch (either amending a commit or pushing a new commit) this 
>> creates a new "version" of the merge-request that you can diff against 
>> previous versions. The bad thing here is that comments are not always 
>> carried over as they should be. There is also no way of marking a file 
>> as reviewed, so large reviews can be cumbersome. The good news is that 
>> this stuff is improving slowly. 
> 
> Yep, that's all great info.
>> Gerrit is a much more powerful tool for code-review. The workflow is 
>> less intuitive however and has a far higher learning curve. 
> 
> I disagree, but please can you clarify which version of Gerrit you are 
> referring to?  The latest release (2.15) is an enormous leap forwards in 
> usability:

Feel free to disagree, this isn't based on opinion on my part but 
experience, I have migrated two companies (with around 20-30 developers) 
to gerrit and gitlab respectively and developers have adjusted far 
faster to gitlab than to gerrit. The version was pre-2.15, 2.13 I 
believe, but nothing revolutionary seems to have happened (the same 
patch-set based workflow).

Personally I much prefer gerrit, but I have been using git since 2009 
including kernel coding which puts higher requirements on skill than 
most systems. For your average developer Gerrit is a lot harder to 
adjust to it seems.

> https://gitenterprise.me/2017/11/15/gerrit-user-summit-whats-new-in-2-15/
> 
> and there are more big leaps coming in 2.16 too.
>> It requires specific hooks to be installed to work well 
> 
> AFAIK it only requires one hook, and this is automatically set up when 
> you run "git review" the first time in the repo, so I don't see that as 
> a significant hurdle.
>> and works by a "patch-set" concept. You push your changes to a "for" 
>> branch, i.e. "for-master" 
> 
> Actually you can give the branch any name you want; it doesn't have to 
> have the "for-" prefix.  Perhaps you are referring to the refs/for 
> namespace:
> 
>     
> https://gerrit-review.googlesource.com/Documentation/concept-refs-for-namespace.html 
> 
> 
> but this is mostly an internal implementation detail; in practice 
> everyone uses a tool such as "git review" which handles all that 
> automatically behind scenes.

Yes, extra tooling is more or less the norm when using gerrit.

>> and they then end up on an unnamed branch on the server in a review. 
> 
> Technically speaking it's a ref not a branch, but same principle :-)
>> From there they can be pulled and tested.
>> The code-review is top-notch, with comments attached to a version of 
>> the patch-set and intra-version diffs being quick and elegant.
>> The negative sides of Gerrit typically outweigh the positive for most 
>> organizations I'm afraid:
>> - No central hosting like gitlab.com. 
> 
> That's not really true.  There are SaaS hosters of Gerrit, most notably 
> GerritForge who also offer completely free hosting for FLOSS projects on 
> http://gerrithub.io/ (although note that this particular free service 
> uses GitHub as the "back-end").

Github -> github.com
Gitlab -> gitlab.com
Gerrit -> many alternatives. I.e. not central.

>> - High threshold for new contributors (unusual workflow, hooks needed. ) 
> 
> I keep hearing this and I just don't understand it, sorry.  What's 
> unusual about the workflow?  You create a branch, commit to it, and then 
> type "git review".  Could it really be much simpler?
> And Gerrit requires about the same amount of setup as GitHub.  I already 
> addressed the hooks comment above.  I think most people forget that 
> GitHub requires some setup because they already did it so many years 
> ago.  If you have specific thoughts on this I'd love to hear them so I 
> can understand your viewpoint better, because like I said you are not 
> the only person I've heard this perspective from.

Again, not opinion. Painful experience.

What you outline is the trivial use-case, and using an additional tool 
"git review". The more advanced use-cases are things like responding to 
a review with new commits, or a complete re-write of the contribution. I 
spent a lot more time supporting users on Gerrit when doing these things 
than I did Gitlab users.

Anecdotes on offer include things like "I re-cloned the the repo and my 
branch isn't there even though I pushed it". You then need to explain 
about refs/changes/... and that they need to find their review there and 
create a branch again from the correct change, which they first need to 
fetch.

Gerrit is a fantastic tool, but it isn't for everyone is my conclusion. 
I wish it was, because the code-review is pretty unbeatable.

>> - No bugs/issues etc. 
> 
> That's one of the awesome things about http://gerrithub.io/ - you get 
> first-class code review but with all the nice other features offered
> by GitHub.

I.e. external tool.

I don't really want to spend more time on this discussion (it's pretty 
off-topic for the list). My opinion is simply that Gerrit is the better 
tool for most purposes, but some developers will feel the threshold is 
too high and may not contribute. Gitlab is inferior for code-review but 
much more accessible and comes with more included. I will be happy 
either way, and also with staying on GitHub for the moment until we see 
what M$ has planned.

/Nils