Research Packit reverse-dependency checks

[lachmanfrantisek]

As part of the cross-team discussion about how to help with #2343 , we've come up with an idea how to approach it:

• Use Fedora on GitLab approach for some projects (we can start with Python package(s) since Lumir was part of the discussion and Python would hugely benefit from this functionality).
  • Ask for a new namespace on GitLab.
  • Setup a distro-sync to make some dist-git projects available there .
• Use Packit as a CI on merge-requests targeting these projects. (We can start with supporting existing upstream jobs.)
• Implement the reverse-dependency builds/tests into Packit. (From all possible approaches, this one looked the most promising since we already have the Copr communication in control.)

So, let's try to think about what would it take to do this:

• Take a look at this approach and write down main tasks and possible issues we might need to resolve if we need to implement this.
• Write down concerns and riscs of this approach.
• Think also about possible configuration.
• Take a look at how we can use Copr for running reverse-dependency builds. (You can get inspired by mass-prebuild or ask Lumir how they are doing this.)
• Organise a discussion within a team and present the findings.

[frenzymadness]

I'm thinking about it and have a question: isn't „Fedora on Gitlab“ too big change to start with? I mean, there are many questions around this and I'm afraid they might block the reverse dependency builds. For example: if a package is onboarded to Gitlab, is pagure disabled for it? If not, what will happen to PRs open via Pagure? What will be UX for the maintainers?

[lachmanfrantisek]

@frenzymadness Good point, Lumír.

A lot is still unclear and that's why I've created this spike card...;)

I don't know many details about the OSCI tooling, but I would say it takes care only of the sync. At least for the start, it would probably be on you, as a maintainer, to disable pull requests on Pagure site if wanted:

For us, the difference between GitLab/Pagure from the implementation point of view is not the hardest part of the implementation. If the FedoraOnGitLab won't work, we can do the Pagure support. Maybe the GitLab is just more future-proof. The crucial part is to handle these PRs as dist-git content and the reverse-dep logic itself.

• For the user, ideally, it shouldn't matter -- it would still be a pull request on a git-forge.
• Fort the maintainer, it might be messy to review both places. So, it's probably better to allow contribution only in one place and clearly document the process in the other.

[lachmanfrantisek]

Maybe just one concern -- how the user rights can be handled on GitLab. If we force people to create a GitLab account and also if the maintainer permissions can be synced.