Follow-Up: GitHub or Gitlab?


#21

Yes, GNOME uses GitLab Community Edition. See https://gitlab.gnome.org/help


#22

Hey, GNOME’s GitLab admin here.

@JohnMH Your offer is really nice, but I have to say that Sanja is right here. Maintaining your own GitLab CE it’s not trivial enough to be maintained just voluntarily and not widely supported by an organization. At GNOME we have a paid half time person doing the backend sysadmin stuff, and me doing the more administrative part.

It’s has small details that gitlab.com or github.com just take care of them already. For instance, some day SilverBlue will want to set up gitlab pages, and then you have to deal with domains, and also with redirections, etc. Same for CI, or tons of features gitlab has. Same for abuse reports, spam, etc.

Personally, I would love for Fedora to have its own GitLab CE, but I don’t think it’s a good idea if it’s not maintained widely and officially by Fedora as an organization itself, specifically with someone paid to do it.


#23

Why not Pagure?


#24

You should check the link mentioned on the first post by @sanja.


#25

:man_facepalming: it’s a shame


#26

@JohnMH Your offer is really nice, but I have to say that Sanja is right
here. Maintaining your own GitLab CE it’s not trivial enough to be
maintained just voluntarily and not widely supported by an organization. At
GNOME we have a paid half time person doing the backend sysadmin stuff, and
me doing the more administrative part.

Respectfully, I would have to disagree. In my opinion, maintaining GitLab CE
isn’t a complex task at all, even with custom patches.

It’s has small details that gitlab.com or github.com just take care of them
already. For instance, some day SilverBlue will want to set up gitlab
pages, and then you have to deal with domains, and also with redirections,
etc. Same for CI, or tons of features gitlab has. Same for abuse reports,
spam, etc.

The major difference here is that both gitlab.com and github.com are
proprietary platforms. Using GitLab Pages for Silverblue sounds like an
awesome idea, a declarative website for a declarative system. That isn’t
something that would only be usable on gitlab.io or github.$something.
Splentity uses GitLab Pages on wildcards of splentity.site.


#27

For me, it’s a relatively tough choice.

I generally prefer GitLab, but with 5 other Fedora projects already being hosted on GitHub, it’s hard to make the call to make Silverblue standalone on GitLab. Being on GitHub would also make it simple for others to contribute to all these projects, as opposed to having a GitLab account for Silverblue, and a GitHub account for the other 5. With that being said, GitLab CI is very nice to work with, and I really do enjoy how GitLab is laid out.

Regardless of which decision is chosen, I don’t think we should immediately go for a self-hosted solution. We simply don’t need that extra overhead right now. What we need right now is a reliable, hosted solution that requires minimal initial input to get things rolling.


#28

Private repos is irrelevant for this poll (and Fedora), as is the integration with Azure pipelines.
Besides, GitLab also has unlimited private repos and integrates CI in the form of their own GitLab CI.
But as said, this is irrelevant.

What is better for Fedora; we publish our docs and collect issues on either of these platforms.


#29

You can easily log in on GitLab via a GitHub account, not an issue at all.


#30

thanks for the correction! I wasn’t aware of this.


#31

GitHub is proprietary software with a near-monopoly, which happens to be owned by one of Silverblue’s largest competitors. You cannot use it to contribute without a GAFAM surveillance account (so personally I refuse to use it on principle, and Silverblue won’t change that). We should actively oppose it.

GitLab EE is proprietary software whose team have worked closely with GNOME over the last few years to improve open source software — GitLab CE — so that it’s suitable for GNOME’s needs. There is some work towards allowing merge requests from other GitLab instances, such as GNOME’s.

Neither is fully aligned with our principles, but GitLab is much closer.


#32

I’d also argue that using GitLab is the future. GIMP, Mailman, Inkscape, GNOME, RedoxOS, Purism and so on are now all using it now, and I suspect many many more will follow soon. I expect the amount of contributors would rise a lot simply by using the same platform that the projects above do.


#33

Judging by the poll, we are still a very much split community on this question. I have been to GitHub and GitLab and only have experience with using GitHub and cloning from GitLab so GitHub is more familiar to me. However, GitLab is itself not that much different it would seem as far as the forward facing bits go, and if it is more in line with our Fedora Communities Four Foundational Principles than I think it does become the obvious choice on that merit alone. The fact Gnome is there is an important consideration, also the heart of Silverblue is derived from the Gnome Continuous OS project, or that was the impression I was under at least.


#34

HAHAHAHAHA! From that page:

Screenshot%20from%202019-01-27%2010-11-43

#JustSayin


#35

GNOME isn’t really “there”, though, as they’re running their own dedicated instance of GitLab CE. I’m not aware of any advantages being on hosted GitLab would offer over being on hosted GitHub, in terms of interoperating with gitlab.gnome.org. (Carlos or someone can probably correct me if I’m wrong there?) Unless there are, not really all that relevant.


#36

Ah, I see what you’re saying. However, in the world of perception, which is basically what the difference between GitHub and GitLab boils down to if there are no supporting technical aspects that can clearly point to one or the other as “more open”. In that sense GitLab has the perception of being more open. It does not do any good speculating whether MS/GitHub will become Open Source, or if GitLab will go in the other direction and become less, again in perception. Also, the elephant in the room that doesn’t seem to be registered currently is what does RedHat and their parent (IBM) have to say about how they see the fedora community since RH and Fedora are tied at the heart. Surely they (IBM) had a business plan in mind when they purchased RH.


#37

It is not possible for GitLab to be come ‘less open’. If they change the
license of GitLab CE, we will still be able to use the last release of GitLab
CE under the current license.

Please do not spread FUD about IBM/Red Hat…


#38

I’m not trying to spread anything of the sort, especially Fear, Uncertainty and/or Doubt. I personally don’t have a problem with the relationship as it stands, and there is no reason to think it will change in the future, at least none that are apparent to me. As far as I can see historically speaking IBM has embraced the Open Source Community philosophy. My point was intended to be that the differences between a proprietary format under a community license and a proprietary platform hosted by a closed source vendor, both built upon open source code (git), is merely arguing semantics, again in my opinion. If the community is steadfast in it’s position that Silverblue docs source should be hosted on a totally open source/free solution then some members should be stepping up to address that, which includes Pagure developers. I don’t know anyone in any of these circles other than their online persona, your’s included @JohnMH. I do however, value the community in general, and those who contribute which includes you @JohnMH , since the end result I get to use is so usable. For that, each and every contributor will forever have my gratitude and I will champion their SW cause to anyone who will listen. I want to do more than appreciate, and that means contribute, so I am trying.


#39

Of course it’s possible, especially since GitLab isn’t fully open-source even today. GitLab CE is, yes, but that’s only a tiny fraction of GitLab’s available functionality, even for self-hosted environments.

Basically every feature on this list that doesn’t have a check-mark in the leftmost column is a GitLab EE feature that’s not part of the GitLab CE distribution, and would have to either be paid for or reimplemented locally to be part of a self-hosted GitLab CE installation. That’s a lot of features. And while most of them may be irrelevant/unnecessary, maybe comparisons between GitLab and GitHub should focus on the differences in that part of the featureset.

Just as one random cherry-pick: Merge Request Reviews

That’s a second-tier (Premium Silver) paid feature in GitLab (dotcom or CE), whereas it’s available to all GitHub users, even free accounts.


#40

My longer reply quoting from GitLab’s product matrix got spamcanned and still hasn’t shown up. In the hopes that it eventually will, I’ll just quickly summarize:

GitLab CE is only a small portion of the GitLab featureset even today, and anything beyond that which isn’t part of CE would have to either be paid for or reimplemented locally. That’s true regardless whether we consider the dotcom or self-hosted scenario. And it’s a lot of features, including some that GitHub makes available to all users (even free accounts). Perhaps comparisons between the two should focus on those. (“Merge Request Reviews” was my cherry-pick.)