On Tue, Jul 23, 2019 at 07:18:56AM -0400, Neal Gompa wrote: > On Tue, Jul 23, 2019 at 5:47 AM Kevin Kofler <kevin.kof...@chello.at> 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.
On the other hand, large FOSS projects are using it. Perhaps we should actually talk with the GitLab folks before deciding they will or won't do something. I've heard they're pretty cool folks. > > 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... Sure, sure, but Pagure has regressions too, and plenty of things just don't work for years at a time because it has a fraction of the resources. As a Fedora contributor primary attraction to GitLab to me is that other communities are using it and we can work together. As a user, GitLab's user experience is vastly better. I find Pagure's user experience for code review and CI to be incredibly painful to use. - Jeremy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
