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

[Adam Spiers]

Nils Carlson <nils.carlson at ludd.ltu.se> wrote: 
>On 06/11/2018 03:18 PM, Adam Spiers wrote: 
>>Nils Carlson <pyssling at ludd.ltu.se> wrote: 
>>>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). 

2.15 *is* revolutionary in terms of UX because the UI was rewritten 
from scratch (PolyGerrit).  True, the workflow is more or less the 
same in design, but how intuitive it will feel to newcomers (your 
original criticism above) depends heavily on the UI. 

>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. 

Yes, as an occasional git hacker I'm in a similar boat. 

>For your average developer Gerrit is a lot harder to 
>adjust to it seems. 

Yes, like I said I've heard this several times, but in the absence of 
concrete details I'm really struggling to understand how this could be 
more than natural inertia rather than genuinely significant practical 
hurdles.

However I'm not only willing to be proven wrong but actively seeking 
good explanations which *would* prove me wrong.  This is because I've 
already volunteered to write a document which helps people familiar 
with GitHub migrate to Gerrit (intended for the OpenStack community 
but of course it could be shared to a wider audience).  And to do that 
well I really need help understanding what people struggle with when 
learning Gerrit the first time.  So if you can help with that I'd be 
really grateful, although don't worry if you don't have time :-) 

[snipped]

>>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. 

It's pretty common with GitHub too, I suspect.  But even if not, I 
don't see a one-off installation of a simple tool as a huge hurdle. 

Furthermore, without a helper tool or IDE which supports GitHub or 
GitLab, creating a pull request or merge request requires several more 
steps than with Gerrit: 

  0. Ensure that you have a remote fork to which you have push
     access (e.g. by clicking the merge button if you don't
     have push access to the target repository)

  1. Push your branch to a remote fork

  2. Locate that branch in the web UI

  3. Click the button(s) to bring up the window in which you
     draft the pull/merge request

  4. Give the request a title and description

  5. Submit it

Compared to the single step "type git review", I'm somewhat mystified 
how anyone can claim that Gerrit is harder to get started with. 

>>>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. 

Why is that a problem though? 

>>>- 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 

With Gerrit: 

  1. Add / amend commits

  2. Run "git review"

With GitHub or GitLab: 

  1. Add / amend commits

  2. Run "git push", optionally with --force-with-lease, which requires
     a fairly deep understanding of the implications of rewriting git
     history.  This is a sufficiently complicated topic that I've
     blogged about it twice to try to help reduce confusion:

       https://blog.adamspiers.org/2015/03/24/why-and-how-to-correctly-amend-github-pull-requests/
       https://blog.adamspiers.org/2017/08/16/squash-merging-and-other-problems-with-github/

>or a complete re-write of the contribution. 

With Gerrit: 

  1. Create new branch and commit the rewrite to it

  2. Run "git review"

  3. Abandon the old review with a comment linking to the new one.

With GitHub or GitLab: 

  1. Create new branch and commit the rewrite to it

  2. Go through the 6 steps I listed above for submitting a new
     pull/merge request

  3. Abandon the old review with a comment linking to the new one.

>I spent a lot more time supporting users on Gerrit when 
>doing these things than I did Gitlab users. 

I don't dispute that.  But I'd love to hear more about the concrete 
reasons why. 

>Anecdotes on offer include things like "I re-cloned the the repo and 
>my branch isn't there even though I pushed it". 

Yeah, that's a very good point that users who are used to pushing 
their changes somewhere central would need to relearn the new model. 
And thanks - that's a useful point I can capture in the document I'm 
working on.

But I still disagree that makes Gerrit inherently more complicated; 
it's just *different*.  In fact the number of steps in the processes 
listed above show quite clearly that its lack of requirement to first 
push changes somewhere central significantly simplifies usage. 

>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. 

There's no need to explain about refs/changes/... at all; just point 
them at git review -d: 

  -d CHANGE, --download CHANGE
       Download the contents of an existing gerrit review into a branch

Another simple one-liner. 

>Gerrit is a fantastic tool, but it isn't for everyone is my 
>conclusion. 

Is *any* tool for everyone? ;-) 

>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). 

Well, it's clear that some key people here aren't familiar with 
Gerrit, so I hope this is helpful to them at least. 

>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. 

I agree with all of that.  I just feel that most of the developers who 
feel that the threshold is too high are not looking at it in an 
objective way.  But as I said before, I'd be happy to be proven wrong 
by being shown concrete examples of why the learning curve is steeper 
than it appears to me, because that would help me write a better 
migration document. 

Thanks a lot for sharing your thoughts!