[ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?
jpokorny at redhat.com
Fri Jun 8 08:12:14 EDT 2018
On 07/06/18 11:10 +0000, Nils Carlson wrote:
> On 2018-06-07 08:58, Kristoffer Grönlund wrote:
>> Jan Pokorný <jpokorny at redhat.com> writes:
>>> AFAIK this doesn't address the qualitative complaint I have. It makes
>>> for a very poor experience when there's no readily available way to
>>> observe evolution of particular patchsets, only to waste time of the
>>> reviewer or contribute to oversights ("I'll skip this part I am sure
>>> I reviewed already, if there was a generational diff, I'd have a look,
>>> but the review is quite a pain already, I'll move on").
>>> No, setting up a bot to gradually capture work in progress is not
>>> a solution. And pull-request-per-patchset-iteration sounds crazy
>>> considering this count sometimes goes pretty high.
>> 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
> 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.
> 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.
I must admit, this would be a killer feature for me (see the above
rant) and best trade-off if the willingness to try/adopt Gerrit
> 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
> Gerrit is a much more powerful tool for code-review. The workflow is less
> intuitive however and has a far higher learning curve. It requires specific
> hooks to be installed to work well and works by a "patch-set" concept. You
> push your changes to a "for" branch, i.e. "for-master" and they then end up
> on an unnamed branch on the server in a review. 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.
> - High threshold for new contributors (unusual workflow, hooks needed. )
> - No bugs/issues etc. But good jira integration.
> I haven't tried pagure. There is also gitea which looks promising. And
Thanks for sharing your thoughts, Nils, appreciated.
P.S. Your post may be stuck in the moderation queue, hopefully this
is resolved soon (as a rule of thumb, I recommend subcribing to
particular list first if not already, but there can be additional
anti-spam measures for first-time/unrecognized posters).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Developers