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

[Adam Spiers]

Kristoffer Gronlund <kgronlund at suse.com> wrote: 
>>On 07/06/18 08:48 +0200, Kristoffer Grönlund wrote: 
>>>Jan Pokorný <jpokorny at redhat.com> writes: 
>So GitLab has a problem that AFAIK even GitHub didn't have, where 
>certain crucial features are only in the enterprise edition - 

You're portraying GitLab as worse than GitHub here, but your logic is 
backwards ;-)  *All* of GitHub's functionality is non-libre, whereas 
only certain features of GitLab are. 

>though they did announce the special allowance for open source projects the 
>other day which I don't know the details of. 

    https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/

>And of course GitLab risks being acquired not by Microsoft but whoever 
>else

    http://uk.businessinsider.com/gitlab-raises-20-million-from-gv-2017-10

>so again, not sure how much it improves. Unless self-hosting that 
>is.

No, you don't have to start with self-hosting for there to be a huge 
difference between these two scenarios; this is comparing apples to 
oranges.  GitHub's code is not FLOSS; GitLab CE is. 

Microsoft could in *theory* do something unspeakably evil with GitHub 
*today* (although of course they won't, not yet at least).  Whereas if 
GitLab the company decided to say, radically increase their prices, 
any users could migrate either to self-hosting, or to a rival GitLab 
CE hosting company which would inevitably spring up to compete with 
the original GitLab company.  With GitHub, there is no nearly 
identical equivalent to migrate to without significant disruption, and 
there never will be as long as GitHub remains proprietary. 

May I remind you that we both work on FLOSS for the same pure-FLOSS 
company which was acquired multiple times ;-)  And during or after 
these acquisitions, none of the FLOSS projects sponsored by our 
company somehow magically turned into evil proprietary technology. 
Copyleft guarantees that that cannot happen. 

>Pagure has the benefit of being written in Python which I'm comfortable 
>with so yeah, maybe we can fix any problems with it ;) 

"I'm comfortable with" ... "we can" - hmm, there is a gap in your 
logic here, but I guess that's what the smiley was for ;-)  But 
seriously, even if we pretended you weren't already an experienced 
Ruby developer, it would be easier for you as a Python-only dev to 
learn Ruby and start hacking on GitLab CE, than to first bring Pagure 
up to feature parity with GitLab CE.  I'm not hugely familiar with 
Pagure but it seems hugely under-powered in features compared to 
GitLab.  I'm really curious why it was decided to reinvent the wheel - 
perhaps a misguided Python vs. Ruby thing?  If it was only an ethical 
objection to the GitLab's open core model then it would have been far 
easier simply to fork the core. 

In any case, this makes for interesting reading: 

    https://lwn.net/Articles/724986/

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

Yes, Savannah is awful :-( 

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

Yes, this is *exactly* what GitHub gets so badly wrong and Gerrit gets 
so right.  I have already done a lot of work documenting this, e.g. 

    https://ethercalc.openstack.org/github-gerrit
    https://github.com/isaacs/github/issues/997
    https://github.com/isaacs/github/issues/998
    https://github.com/isaacs/github/issues/999

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

TL;DR: GitHub code review sucks horribly (the details can all be found 
in https://github.com/isaacs/github/issues), whereas Gerrit doesn't. 
And with heavy investment from Google, Gerrit is getting dangerously 
close to being awesome.  If you want to have a quick play with it, 
take a look at 

    https://android-review.googlesource.com

or

    https://review.gerrithub.io/

which is Gerrit providing code review on top of some GitHub repos. 
(*Don't* look at the OpenStack Gerrit which is a very old version 
missing the more recent total revamp of the UI.) 

>>In the short term, I'd suggest concentrating on the two points I raised: 
>>- good discipline regarding commit messages 
>>- more systemic approach to release tarballs if possible 
>
>Both of these are generally good suggestions, I agree that we should 
>make an effort regarding commit messages. 

+1

>On the other hand, there is a 
>balance between having good commit messages and lowering the threshold 
>of contribution from outside developers. 

Having bad commit messages raises the threshold of contribution for 
*everyone*; please don't start down that slippery slope ;-) 

    https://wiki.openstack.org/wiki/GitCommitMessages

It's pretty easy to gently and politely help new contributors to 
improve their commit messages to the point that they can be merged 
without compromising on high standards.  And in the process the new 
contributors learn how to collaborate better.  Everyone should be 
given the opportunity to learn the ropes.  Turning a blind eye to poor 
quality doesn't help anyone.