Ideal delivery date: End of 2022 Q4, or 2023 Q1
Provide a short-term basis migration tool to import Pagure repos, issues, and pull request history into a new GitLab project.
Many teams are shifting from Pagure to GitLab. One common barrier raised across multiple team meetings is how to preserve historical discussion and decisions from issues and pull requests, in addition to the git repository itself. Currently, there is no clear pathway about how to take this history with us.
This is similar to a short-term initiative that Fedora Infrastructure ran in 2015 to 2016 when we moved from a hosted Trac system to Pagure. Many Pagure repositories include data and history that can sometimes be decades-old. This data is invaluable to the Fedora Project as a historical archive and should be preserved. In a similar way to how a CLI client was created to offer a self-service method for moving from Trac to Pagure, there is a strong need for such a mechanism for moving from Pagure to GitLab.
The key benefit of this mini initiative is that it unblocks adoption of GitLab for several teams. Data preservation would no longer be a cost associated to GitLab. Historical decisions are easily referenceable and discoverable in the new system, across several Fedora repositories and the wider GitLab ecosystem.
A possible downside of this mini initiative is that two account systems are being accessed (FAS and GitLab.com), and imperfect matches might be made. Is it possible to link a Pagure account to a Fedora-linked GitLab account? This would allow Fedora contributors to "import" their Fedora contributions to their GitLab profiles, but might come at an added cost for developing such a tool.
A self-service tool is an effective option for CPE because it enables contributors to scratch their own itch without requiring human intervention to migrate a repository. The tool could be supported for a limited lifespan (e.g. 6-12 months) before it could be retired. This would allow a window of time for Fedora contributors to make a calculated jump and bring their repository history with them.
Completion by the end of 2022 would be helpful for teams to shift into the new year by adopting a new workflow, but this could happen on a longer timeline. If implemented, it would unblock some teams from adopting GitLab.
Will this initiative impact CentOS, Fedora? All users? All contributors? A group of contributors (which)? Any Pagure user. This can be Fedora and CentOS users. This could potentially be a useful tool for a "someday" down the line of whether dist-git moves from Pagure to GitLab too.
Is this initiative under a time-constraint? Should it start or end before a certain date?
End of 2022 or early 2023 would be incredibly helpful to unblock workflows of several teams that are waiting on the answer to the question about historical data. This is confirmed to include but is not limited to the following:
It would be a slam-dunk if GitLab would support this officially as part of their New Project Importer:
https://gitlab.com/projects/new#import_project
The Pagure to GitLab importer investigation is now finished
After a backlog refinement session with the CPE team, we have decided that due to the non-critical nature of this request, it is unlikely to be formally staffed with a project team and should move to our infra & releng teams work queue instead to be worked on through that path. Closing this ticket as a new one is now open on fedora-infrastructure https://pagure.io/fedora-infrastructure/issue/11542
Metadata Update from @amoloney: - Issue status updated to: Closed (was: Open) - Issue tagged with: Dropped
Log in to comment on this ticket.