Move Docs to GitLab

This was also discussed on the old mailing list before the move here to discussion
Project organisation - docs - Fedora Mailing-Lists

There is now a gitlab “instance” for use by Fedora Subprojects (like us here at docs).

I propose we move the docs project sources (the ones that the docs project controls) to a new sub-group at The current sources (and many old sources that are no longer in use) are housed at:

This will give us a few benefits:

  • We can create further subgroups under the docs group – allowing us to organise better (User docs, team docs, tooling, application docs, etc)
  • We can view issues over all the various subgroups – easier to keep track.
  • There are a lot of old sources and repos that are no longer in use. WE can archive them on pagure and not move them over.
  • the workflow for editing files is much better on gitlab – allowing contributors to do quick edits in the browser.

I’m slightly in favor of this as it will most likely make things easier to find. But it will also require us to mark all existing repos as “archived” and add a big link to the new one.

To begin a checklist if we go ahead with this:


Could we set up the pagure repos to (one-way) mirror the Gitlab one?

I’m generally in favor of us moving a lot of stuff to Gitlab[1], but one valid concern is that we have no formal agreement with Gitlab to provide continuity of service, and if something happened there[2] it’d be nice to not to have to scramble to find backups.

  1. see GitLab available for Fedora - #6 by mattdm ↩︎

  2. they’re bought by EvilCorp, EvilCorp tries to squeeze us? ↩︎


we can mirror the repos in – it will involve a bit of organization during / after the move (and also manully adding mirrors when we all new repos too)

AFAICT, there is no way in pagure to mirror a whole gitlab group / subgroup. only indivudal repos

1 Like

What kind of metadata does GitLab allow us to attach to repos? Could we use that plus the webhook-to-fedora-messaging bridge + toddlers to set up something automated? More work up-front, but then less later.

Doable i think!

Also, have done a quick structure of how we might organize the group here:

1 Like

It will be extremely interesting to read a postexodus writeup on Pagure. Why moving out? What made it hard to implement groups and subgroups there? Was Pagure data model and architecture flawed from the start for this purpose (is there documented data model at all)? Does Pagure support custom issue query interface, or it is UI only? What is missing from Pagure online editor? I would actually expect Pagure to reuse some good stuff from Trac, which is still superior in terms of modularity than GitLab (wiki processors etc.), but whatever.

1 Like

I would specifically like to know what makes gitlab so much more powerful that we host central Fedora projects at a commercial, for-profit company instead of on our own Fedora infrastructure. And by doing so, we force all Fedora contributors to take the risk of having their data and activities tracked commercially and seeing their data sold. I absolutely do not like this. And I am seriously considering to stop contributing.

I get you may not like GitLab, but this move was happening for more than a year ago. There was a AMA and there was an explanation on why. I think that is a little late to look surprised and make a call about dropping.

The main idea is to have less infra to maintain, and there are tons of Open Source Projects using it:

I understand the feelings, but I think that GitLab is powerful and it deserves trust, since there is no signs or news anywhere about GitLab selling data.


7 posts were split to a new topic: Docs move to Discussion from mailing list

Hi Peter. Sorry for the slow reply here.

There are a number of advantages GitLab gives for documentation in specific.

Pagure allows rudimentary web-based editing, but it’s just presenting a basic web browser form. This can be really frustrating (not theoretical — I’ve gotten that feedback from users). GitLab has what it calls a “WebIDE”. There is even work in progress for that to support AsciiDoc previews. Although long-term docs-teams writers will probably prefer a local checkout, this is essential for drive-through contributions — and really, contributions from anyone for whom git is an intimidating barrier.

GitLab also has a much more rich user interface for reviewing proposed changes — “Merge Requests” instead of “Pull Requests” in their parlance. Rather than disconnected comments, individual comments can be grouped into a coherent review, and that review can be updated. And, as part of that discussion, parts of the conversation can be marked resolved individually — making it much easier to work through a big change.

Plus, the Merge UI itself is just a lot friendlier.

I think using Pagure presents a technical barrier to contribution for a lot of potential writers. These two things are big in my eyes, but there are lots of others as well. (For example, the ability to gate a merge request on an external confirmation.) I wish Pagure was at the same level, but we just don’t have the requisite developer base to even close to keep up. See Issues - pagure - and Pull requests - pagure - for just the backlog — and note how few have been actually resolved in recent times.

I’ve written about this before: I wish GitLab would abandon the “open core” model and make the whole thing open source. I think we have a greater chance of influencing them to make that happen by working with them rather than not. Making a git-forge isn’t the Fedora mission, and if I did suddenly get an influx of engineers, I’d really rather them work on things that make Fedora infrastructure better, or improve Fedora Server itself.

I hope you can accept this compromise. We can also look at making ways for people who don’t want to use gitlab to contribute. That would be more complicated, but fundamentally it’s git, so I’m sure we could figure something out.

On the privacy issue in particular: I also share that concern, but personally I think their privacy policy is reasonable: they respect Do Not Track, and there’s also a central opt out (not one per service or page or whatever), and they conform to applicable global privacy laws.