Nils Carlson <pyssl...@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:
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.
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").
- 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.
- 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.
_______________________________________________
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers
