The replacement would be a system chiefly consisting of three elements - Messages Handler, Dist Git Service and Compatibility Metaservice.
So, looks like a decision to drop Pagure/pagure-dist-git has already been made; in order to do so, a new system which will work as compatibility layer between other services and the new git forge must be designed from scratch and deployed; a new git forge has to be chosen, set up and the data migrated.
Isn’t simpler to continue with Pagure? Who will be responsible for maintaining and running the new compatibility layer tool after it’s deployed? What’s the gain here on dropping Pagure?
I feel like What is Dist-git? is a missing chapter.
I like how the interaction between Dist-git and each other tool is catalogued and represented by a separate page.
I miss same pages for summarizing Dist-git User eXperience stories. I am not aware of Dist-git workflow to see how it fits different forges. Explaining the workflow in a simple and friendly manner would enable people skilled in UX/UI to sketch needed workflows, and then evaluate forges with that design in mind.
We just investigated the possibility, the decision is not ours to make. That discussion is going on here. This solution will work even with Pagure, but give us more freedom in case we ever decide to use something else.
We just looked at the services the dist-git is directly interacting with, it would take us much longer to describe whole packager workflow and this was not in the scope of investigation. This is why the links are there for people to look at what those are.
That’s a very good start. I’d move that page into top level section called Workflows, so that it is more visible. And renamed it to Fedora Packager’s Workflow.
The current description is missing the workflow when the Packager edits specs online. It is the same as PR based workflow, but the PR is created through forking and editing in Pagure interface. As I don’t know what dist-git does, I can’t say if that makes sense here.
We just looked at the services the dist-git is directly interacting with, it would take us much longer to describe whole packager workflow and this was not in the scope of investigation.
It is still worth to add a Basic Workflow section that describes intended operations from a typical day of dist-git user. Especially if it is not described anywhere.
I don’t even know if this is recommended way of doing that, all of this should be done through fedpkg as a packager of the project you don’t need to create a fork of the repository. In our proposed solution this kind of operations will be handled by the git forge directly.
I would like to see that in packager documentation as this is not part of this investigation, but is definitely useful for Fedora packagers.
dist-git is not a product, exactly; it’s a term for the overall concept that Fedora package definitions (spec files, source lists, and patches) are stored in git repositories, and the build system (that’s Koji) retrieves those things from git when performing a build. The name was logically derived from the predecessor system, referred to as dist-cvs, which stored all those things in CVS. It also refers to the concrete artifacts of the concept - the git repositories themselves.
“Pagure Dist Git” is the specific Pagure instance that acts as a forge-style interface to the dist-git system, which predates it (before we had a Pagure instance, we had a cgit instance on dist-git for read-only web viewing).