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 gitlab.com/fedora/docs. The current sources (and many old sources that are no longer in use) are housed at:

https://pagure.io/group/fedora-docs

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

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:

2 Likes

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? ↩︎

8 Likes

we can mirror the repos in pagure.io – 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

2 Likes

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.

2 Likes

Doable i think!

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

3 Likes

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.

2 Likes

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.

6 Likes

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 - Pagure.io and Pull requests - pagure - Pagure.io 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.

7 Likes

I fully agree with that. We lost at least 3 authors for our server documentation, for whom as non-programmers the Git workflow was just too much work (in addition to the limited adoc tool set).

Yes, indeed, but the secure operation of a software repository is a core task. Perhaps I am irrefutably damaged by the SourceForge fall from grace years ago. We had a major software project there. It was a nightmare. And that was just the first of similar accidents. Your suggestion to mirror Fedora gitlab to pagure would greatly mitigate the consequences in the event of a MCA.

I haven’t looked at this closely, but could it be that the Debian project has greater control? Nevertheless, yes, ultimately there are enough reasons to trust Fedora Council and Infrastructure!

Perhaps it would be good to inform about the privacy policy in a highly visible place, especially about what means Fedora has to assure itself of the actual compliance with the agreements made and to detect possible abuses.

Best
Peter

5 Likes

I’d like to add something:

GitLab once merged a controversial MR about doing “business with customers with values that are incompatible with [GitLab’s] values”, which was later reverted after massive pushback.

As a huge GitLab fan myself, while I do appreciate GitLab reverting the MR, the fact that this was even merged to begin with really shows its shadiness, although I appreciate GitLab’s honesty and openness because the majority of companies will never say something like this.

I’m not giving reasons to avoid GitLab, as I was one of the people that asked to migrate to GitLab, but I suggest keeping an eye on them and see if they do anything stupid. At the end of the day, they’re a company, so profit is the priority, not the people.

2 Likes

Exactly! That is my point, the tools is very good and a lot of Open Source projects are using it, so let’s use it and keep our defenses up.

3 Likes

Is there anybody tracking these limited issues to give others an ability to collaboratively hack such problems?

I, for one, am hugely in favor. The way the current repositories are organized on Pagure is difficult to find and this has been a thorn in our side for years.

Probably the easiest way to do this after the move is to push a commit that drops all the content and updates the README to point to the new repo on GitLab.

I am asking this seriously, but do we have such an agreement with Red Hat CPE? I vaguely remember a discussion a year or more back that maybe Pagure would go away, but I remember that it was back-pedaled.

I am curious about the maintenance story behind Pagure and whether this has changed in 2022. This was always a concern with regards to bus factor and finding both people outside Red Hat and also inside Red Hat who would commit engineering resources to its future. I don’t know if this has changed in the present or if the Pagure maintenance story is still a burden.

My assumption is the Asciidoctor community would be the most informed on these kinds of topics. I’d love to see more dev tools and beginner-friendly tools with great UX for working with Asciidoc.

1 Like

I meant not topics. but an URL that lists specific issues with the docs toolset that Fedora contributors found limiting.

A post was split to a new topic: Is there a “Writers Guide” for Fedora docs?

One thing you might do regarding continuity is to mirror the Gitlab repos with a Gitea site (Gitea is fully FOSS, unlike Gitlab). If we don’t want to host it ourselves, Codeberg would be an option, too. This way if anything happens with GitLab, everything would still be ready to go on another platform. AlmaLinux is using Gitea now, FWIW.

2 Likes

A post was merged into an existing topic: Gitlab migration plan