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

[Nils Carlson]

On 06/11/2018 08:31 PM, Adam Spiers wrote:
> 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.

Maybe, but I doubt it would change much. People get over the bad UI 
pretty quickly (weeks,) the workflow is the hard part.

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

The difference is really on the IDE side. Eclipse has excellent 
integration with gerrit these days, but most other IDEs do not. 
Configuring your prefered IDE for Gerrit is not trivial in most cases.

I've seen specific tools for GitHub, but never seen anyone use them. 
GitHub does not make use of specific review remotes as Gerrit does, so 
there is no need for specific tooling or configuration. This is the case 
with most of these tools, only Gerrit and Phabricator require/encourage 
specific tooling.

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

As any programmer will tell you, complexity isn't measured in number of 
steps. :-) Each step above is trivial and some are in fact not needed, 
and all are easy to explain.

The above however isn't correct. For an open repo on Gitlab the steps 
would be as follows:

1. Push your commit to a branch of the origin repo (assuming you are 
part of the project, or have push access to a set of branches which can 
be granted to any signed-in user), get a URL on the command line for 
creating a merge-request.

2. Click the URL, review the contents of the merge-request (if you 
pushed only a single commit Gitlab will take the title and comment from 
that commit), click create at the bottom.

Sure, gerrit can do this in one step without opening the we browser, but 
in general most people want to look at the review before forcing others 
to do so.

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

Not a problem, but a barrier to entry. It typically means yet another 
sign-up and yet another account to manage. I can expect most open-source 
interested developers to have a GitHub account, and many have a Gitlab 
account. I also have an account on the Eclipse Gerrit instance, but that 
was only because I really wanted to fix some things. Not everyone cares 
that much.

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

No need to amend force push. Developers who are getting started with git 
and are really fresh can push new commits to the same branch. These can 
be squashed into a single commit at merge time to keep history clean, 
with a "squash and merge" button. It is of course better to do any 
squashing/amending locally, but users have different skill levels and 
pushing them doesn't always lead to good results.


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

Most users don't see it this way. They will run "git reset 
<starting-commit> --hard" to get back to the original state, then create 
new commits and force push. No new review necessary.


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

Gerrit is more complex. If you want to think about it another way you 
can consider that github and gitlab both mantain a 1-1 relationship 
between local branches and branches on the server. Gerrit breaks this 
with the review references. This makes it more complex for the user. Of 
course, one can blindly tell the user to use extra tooling and not think 
about how it works, but that isn't really constructive.

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

I generally follow the philosophy of explaining things to people. 
Ignorance is seldom bliss for programmers.

>> Gerrit is a fantastic tool, but it isn't for everyone is my conclusion. 
> 
> Is *any* tool for everyone? ;-)

No, some people were quite happy in Perforce and ClearCase. Having only 
a single source of truth as in ClearCase appeals to a lot of people.

For a much less kind view of Gerrit you can see this article on lwn.net 
: https://lwn.net/Articles/702177/ .

Cheers,
Nils