Nils Carlson <nils.carl...@ludd.ltu.se> wrote:
On 06/11/2018 03:18 PM, Adam Spiers wrote:
Nils Carlson <pyssl...@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!
_______________________________________________
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers
