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

[Nils Carlson]

On 2018-06-07 08:58, Kristoffer Grönlund wrote:
> Jan Pokorný <jpokorny at redhat.com> writes:
> 
>> On 07/06/18 08:48 +0200, Kristoffer Grönlund wrote:
>>> Jan Pokorný <jpokorny at redhat.com> writes:
>>>> But with the latest headlines on where that site is likely headed,
>>>> I think it's a great opportunity for us to possibly jump on the
>>>> bandwagon inclined more towards free (as in freedom) software
>>>> principles.
>>>> 
>>>> Possible options off the top of my head:
>>>> - GitLab, pagure: either their authoritative sites or self-hosted
>>>> - self-hosted cgit/whatever
>>>> 
>>>> It would also allow us to reconsider our workflows, e.g. using 
>>>> gerrit
>>>> for patch review queue (current silent force-pushes is a horrible
>>>> scheme!).
>>>> 
>>> My general view is that I also feel (and have felt) a bit uneasy 
>>> about
>>> free software projects depending so strongly on a proprietary
>>> service. However, unless self-hosting, I don't see how f.ex. GitLab 
>>> is
>>> much of an improvement
>> 
>> Open-core business approach aside as perhaps necessary downside at
>> these scales, the difference is crucial: Community Edition is open
>> source, anyone can host it individually, which is what enabled
>> both Debian and GNOME to consider it's usage (became a reality
>> for the latter: https://gitlab.gnome.org/explore/groups,
>> https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/)
>> 
>> Feature-wise:
>> https://wiki.debian.org/Alioth/GitNext/GitLab
>> https://wiki.debian.org/Alioth/GitNext
>> https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/FeatureMatrix
>> 
>>> (Pagure might be a different story, but does it offer a comparable
>>> user experience?) in that regard, and anything hosted on "public"
>>> cloud is basically the same. ;)
>> 
>> Pagure has the benefit you can influence it relatively easily, as
>> I directly attested :-)
>> 
> 
> So GitLab has a problem that AFAIK even GitHub didn't have, where
> certain crucial features are only in the enterprise edition - though
> they did announce the special allowance for open source projects the
> other day which I don't know the details of.
> 
> And of course GitLab risks being acquired not by Microsoft but whoever
> else, so again, not sure how much it improves. Unless self-hosting that
> is.
> 
> Pagure has the benefit of being written in Python which I'm comfortable
> with so yeah, maybe we can fix any problems with it ;)
> 
>>> crmsh used to be hosted at GNU Savannah, which is Free with a capital 
>>> F,
>>> but the admin experience, user experience and general discoverability 
>>> in
>>> the world at large all left something to be desired.
>>> 
>>> In regard to workflows, if everyone agrees, we should be able to 
>>> improve
>>> that without moving. For example, if all changes went through pull
>>> requests, there is a "required reviews" feature in github. I don't 
>>> know
>>> if that is something everyone want, though.
>>> 
>>> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
>> 
>> 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 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.

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.

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

/Nils