On Tue, Jul 23, 2019 at 5:47 AM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > Alexander Bokovoy wrote: > > As I said already, my primary worry is where we would clash our needs > > with those of GitLab commercial entity. For example, Kerberos > > authentication or SAML SSO for groups, or push rule restrictions are > > part of commercial offering but not available in the community edition. > > This makes it harder to integrate with existing workflows and existing > > dist-git use. > > Indeed, GitLab's crippleware approach might become a problem. > > With all those high-profile Free Software projects using GitLab, I wonder > whether a fork is in order. > If a fork is necessary for GitLab to be usable for high-profile FOSS projects long-term, then GitLab is a bad fit. The "friendly fork" model won't work, because rebasing and integrating upstream with downstream concerns will be incredibly difficult. The "hard fork" model will fail because GitLab's complexity is incredibly high, making it functionally impossible for a community to maintain the fork over time. It would be a repeat of the Alioth situation all over again... GitLab's CE/EE split model basically makes it impossible for an amicable model of community contributions to GitLab, because large FOSS projects require what they consider Enterprise features. They can and have rejected things based on this in the past, and will continue to do so based on that criteria. Also, for $DAYJOB, I run a GitLab server. If you think maintaining a GitLab server is easy, you have another think coming. GitLab's development model basically makes it impossible to have any real degree of stability, since the codebase churns without concern *very frequently*. Heck, for three months (that is, three GitLab releases!), they broke merge requests in GitLab last year when they rewrote merge requests frontend code in Vuejs... It was that experience that pushed me to look at Pagure for my personal servers and start contributing to it in the first place... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
