The Fedora Docs team is starting the process of moving repos from the fedora-docs namespace on Pagure to GitLab. We’re making this move in order to take advantage of features like improved in-browser editing and cross-repo kanban boards. This move will be entirely transparent to the docs published at docs.fedoraproject.org. However, if you are contributing to one of the repos in this namespace, you’ll need to update the git remote.
FAQ
We expect you have questions, so we’ll try to answer them ahead of time. If you have additional questions, please ask on the #docs tag in Fedora Discussion.
Does my team need to move?
No. This only applies to the repos maintained by the Docs team. Other documentation can be stored wherever the team sees fit. So long as it’s a publicly-accessible git repository, the site can pull from it. We currently have teams using Pagure, GitHub, and GitLab.
When will you move the repo?
We’ll be moving repos one-by-one over the next few weeks. If there are particular repos you’re interested in, you can check the status from the GitLab migration board.
Will open issues and pull requests be migrated?
We’ve decided to take this opportunity to declare bankruptcy. Some issues and pull requests will be addressed prior to moving, but we will not migrate anything left open. Pull requests can be re-submitted once you’ve updated the git remote.
What if a repo shouldn’t be moved?
If you’re the maintainer of a repo in the fedora-docs namespace on Pagure and don’t think it should move, please let us know. It can be migrated to another namespace on Pagure or it can be left as-is. We’re operating on the assumption that repos in the fedora-docs namespace are “owned” by the Docs team. If that’s not a valid assumption, we’ll work with you.
How will this work?
First, we’ll copy the repo to GitLab. Next, we’ll update the staging website to use the GitLab-hosted repo. Once we’ve verified that all is well, we’ll update the production website. The issue tracker on Pagure will be set to read-only and we’ll update the README file. We will leave the old repos on Pagure for a time in order to catch old links.
This feels like a potentially missed opportunity to add mirroring features to Pagure. Git has excellent support for mirroring, and if a bare repo is used (no locally checked-out branch) the mirrors can be maintained in a totally automated fashion.
(A post I wrote @ the GitLab community detailing how I’ve accidentally been maintaining local mirrors of three GitHub projects, because I set it up in a cron job on my account as a proof-of-concept, forgot about it, and it’s been steadily updating every 15 minutes for the past (now) three years. Never once failed or had the slightest hiccup. The only issue I hit was the logs growing too quickly, until I removed some verbosity.)
There’s no reason (other than the lack of an implementation) the team shouldn’t be able to migrate their repos to GitLab, get all of the features they want out of hosting their projects there, but still have the old Pagure repos continue to stay up to date with the latest commits. It’d be like they never left, at least from a source-code perspective.
The “add mirroring features to Pagure” makes this a non-starter. If you look at Pagure development, it’s…unlikely to get major features any time soon. So it’s a nice idea, but I don’t see it happening.
There’s already mirroring features in Pagure. They were added several years ago.