The scenario is simple: how do we accommodate people who are used to work in $git_forge_of_choice, are acustomed to the interface and have all integrations already set up. It will be pretty hard to convince these potential users to jump ships.
As an example, cockpit, anaconda and systemd are used to work in GitHub and have everything set up there, including CI, testing, downstream maintenance branches.
Would mirroring of sources be a solution here? Basically mirror work their are doing to our source-git repos on pagure and bring feedback back to upstream if something goes wrong?
I would say, since at this point at least, dist-git is still the "canonical source of truth" for Fedora, that people can use whatever forge they wish, and there will be varying levels of support there. I thought that packit had some github integrations already? I know that even if we choose Pagure as the forge for source git in Fedora, kernel can not move from gitlab, as there is a workflow there that matches CentOS stream and RHEL. Once this goes a step further, and koji supports building directly from source-git, mirroring might be a solution, but for now, if what we deploy will not get them from $git_forge_of_choice to dist-git, they will have to fill in the gap. For those packages already established somewhere else, they should already have a solution for that.
Pagure supports mirroring, so in cases where a project must be elsewhere, we can mirror into src.fedoraproject.org to ensure Koji can see it. This ensures that everything exists on the local infrastructure and we have all the inputs for building stuff in one place.
Metadata Update from @ttomecek: - Issue untagged with: meeting
Log in to comment on this ticket.