Seeking Feedback: Modernising Fedora Package Submission Process (GSoC Project)

Project Discussion
,
1

Disclaimer

This is just a proposal, not an announcement. We encourage you to provide constructive ideas, just building a proof-of-concept as part of GSoC '25 under the mentorship of František Lachman with strict timelines, we encourage you to provide realistic feedback in a constructive way.

Modernising Fedora Package Submission Process: GSoC Project

This initiative reduces the entry barrier for new Fedora packagers, aligns Fedora’s developer experience with modern Git-centric workflows, and enables package reviewers to focus on actual review rather than manual triage.

There are a number of platforms and tools that one must go through to prepare their package for Fedora and also a lot of work for reviewers as well.

Traditionally, the Fedora package submission workflow involves multiple disconnected systems:

  • Manual spec validation using rpmlint and fedora-review.
  • Bugzilla tickets for initiating package reviews.
  • Manual status tracking and reviewer updates all disconnected from git.

This project introduces a GitOps-inspired approach that integrates these steps into a single automated pull request flow but without changing any of the existing process and providing an easier and more ergonomic alternative.

Idea

We will build an event-driven service that is triggered from a git-forge and sits between Fedora infrastructure and your favorite git forge, let’s say GitHub for example here.

Invoke with Command

Contributors will create a PR with their spec file in their own project repository and trigger the bot in the PR thread.
The GitHub App parses these commands and enqueues the appropriate tasks.

Stage 1: Spec Validation

  • Fetch the .spec file from the PR head
  • Run rpmlint against it
  • Post any warnings or errors as inline comments on the changed spec lines

Stage 2: COPR Scratch Build

  • If rpmlint passes, trigger a COPR scratch build via the COPR API
  • Inside the build, run fedora-review under mock to surface policy or license issues
  • Upon completion, post a summary comment with links to the scratch build logs, or allow the maintainer to iterate if the build fails

Stage 3: Post-Build Inspection

  • On successful RPM creation, enqueue a TMT job that runs rpminspect
  • Aggregate the test outputs and post a concise report (with log URLs) back to the PR thread

Automated Review Ticketing

  • When all CI stages report success, the service calls uses Bugzilla API to file a new ticket for review and posts the status and report of the CI
  • The new ticket number and direct link are added to the PR thread back to GitHub

Live Status Sync

  • The App subscribes to fedora-messaging to listen for any state change
  • Any state change is mirrored as a GitHub status check or PR comment

Merge & Bootstrap (Optional not in scope right now)

  • After reviewer approval (tracked in PR), the maintainer merges the PR
  • Optionally, the service can scaffold the dist-git repo and add a basic Packit config for future updates

Reviewers receive only validated submissions and can conduct reviews directly in the PR, where all necessary context (logs, build status, test results) is available. This eliminates the need to switch platforms. The existing Bugzilla process serves as a log or database for new package submissions, while all activity occurs in the project repository tracked by git.

NOTE: Another direction, we can take is to have a central repository for packages instead of having each of their own where the contributors will file PRs instead very much like how nixpkgs does it.

Timeline

  • June 13, 2025 – Begin development: scaffold the GitHub App and Celery worker, explore integration points with Fedora CI, Bugzilla, fedora-review, and fedora-messaging. Coordinate with Fedora Infra, Packit, and QA teams to align on requirements.
  • June 27, 2025 – Start prototyping: design the CI workflow, integrate initial rpmlint checks, and experiment with triggering jobs from GitHub events.
  • July 11, 2025 – Continue implementation: write tests and build out the bot’s logic for rpmlint execution, GitHub comment handling, and command parsing.
  • July 25, 2025 – Extend the pipeline: integrate COPR scratch builds, rpminspect execution, and automate Bugzilla ticket creation with syncing to PRs.
  • August 8, 2025 – Finalize integration: complete end-to-end testing of the full flow, deploy to an OpenShift environment, and collect feedback from early users.
  • August 22 – September 4, 2025 – Polish and prepare for adoption: refine workflows, improve documentation, and create onboarding guides for contributors and reviewers.

FAQ

Q: What happens if someone doesn’t want to use GitHub?

A: For now, GitHub is the target platform for the MVP because of its popularity and developer-friendly APIs. Support for Pagure or GitLab can be added later.

Q: How does this fit into Fedora Packaging Guidelines?

A: This doesn’t alter any guideline or policy. It simply wraps the existing tools (rpmlint, fedora-review, rpminspect, COPR) into a smoother flow that lives closer to where contributors work (their upstream repo or fork).

Q: How does this differ from the Packit + dist-git + Bugzilla flow?

A: This wouldn’t replace the existing flow but provides an optional interface for new package submissions only. It automates steps like spec validation, scratch builds, and CI feedback before filing the Bugzilla ticket. Packit focuses more on updates and syncing dist-git with upstream.

Q: Will this change what reviewers do?

A: No. Reviewers still decide whether to approve a package. This only reduces boilerplate work for both submitters and reviewers by surfacing issues earlier and gathering logs in one place.

Please share your feedback in the comment below.
The project will be built in public here .

2 Likes
2

So every time we want to submit a new package we have to create a temporary repository for it on a public site that has been blessed with a Fedora agent we can communicate with?

That sounds like a lot of hassle to me, or more likely like something that has been designed around projects that are going to be doing their own packaging and already have a repository to work from.

I do wonder though how this handles the source? A repository can hold the spec file but are we expected to put the source artifacts there as blobs? or is the intention that the automation will download them based on the source lines in the spec? If that is the intention then how will it work for the edge cases where there is no directly downloadable source…

3

I read this as a PoC and not the final form of the integration. Needing to use a shadow repo elsewhere to trigger the tooling I don’t think is the intended final workflow. I think big picture, the intent is this work could be integrated with Fedora’s operation git forge making the need for a separate repo at github unnecessary.

I think some of the choices being made here are in part to time box the project and have something to show in the expected GSoC timeframe. But doing so also means less Fedora packagers are going to test it and provide feedback because of the need to use a github shadow repo. This is an optional tooling experiment, so its just a matter of who is willing to do the extra work with a payoff of potentially getting better automation tooling.

I read github as the intended initiial target as a compromise because Fedora is currently sort of in flux with its git forge. So yeah github as a target is super wonky because its not Fedora’s git forge and adds complexity for anyone who wants to test this. But I would imagine the goal here is to be able to build this in such a way that it would integrate with forgejo, when our forgejo is ready. With a forgejo integration, I would expect Fedora packagers wouldn’t need to have the extra complexity of a shadow repo…it would be something optionally triggerable from Fedora’s git forge of record. We’re sort of in a weird inbetween state right now with project git forges.

More concerningly than the complexity for packagers who want to help test this new work, use of github as initial target does present a risk to adoption of this work by Fedora. it would be less risky if this experiment could demonstrate forgejo integration out of the gate, as we know that’s what Fedora will be using for its git forge soon{tm}. I’d be concerned about possible deal breaker complications if this work used githubisms that made switching to forgejo more difficult (ie. refactoring work noone is going to volunteer to do)

4

Hi and welcome! Thanks for working on this. I’ll leave some initial comments here, but I’d also suggest cross-posting on the devel mailing list where more packagers are likely to see it.

  • I would set up the prototype using Codeberg, the flagship public Forgejo instance, instead of GitHub. Forgejo will be the new Fedora forge, so building this based on GitHub won’t ultimately be very useful.
  • I don’t think the Bugzilla integration is necessary. Why can’t everything happen in the context of the review pull request? Bugzilla will eventually go away, so I don’t think adding another dependency on it is a good idea. One of the main drivers for getting rid of the current process is issues with the Bugzilla UI and it’s unsuitability for code review. Removing this integration should simplify your work a lot.
  • I think having one empty Forgejo repository for all the reviews makes sense. Packagers can submit pull requests to that repository and then once the review is finished, the bot can close the PR (not merge it) and cherry-pick its contents to the package’s new dist-git repository.
1 Like
5

Hi all,

The mentor here..:wink: (So, I have some opinions, but don’t want to push them too hard. Decision is on @manky201 )

Jef is right on multiple points here:

  • Yes, a lot of technical choices are because of this being time-based (the usual issue of GSOC is that it is too ambitious, ending in half). Rather have something really simple, but done.
  • I prefer a single repository as well for this for the same reason as Jef mentioned – might be easier to get experienced packagers into this.
  • Ad, git forge. We’ll hopefully use ogr Python library that Packit is built on top of – this means that a lot of code should be gitforge-independent and since Packit is working on the Forgejo support, we’ll get the Forgejo support for free.
    • But the forge pick is not set to stone and @manky201 might pick anything else based on your suggestion. I would just want to avoid spending too much time on forge-related code compared to the user-facing functionality. (Speaking from the experience when getting GitLab support into Packit.)
6

+1 here. I would not pay much attention to Bugzilla as well, so we can use something like this PoC once we get rid of Bugzilla more easily. (We were a bit too scared to suggest this and wanted to follow the current way of things.) One reason I actually see the Bugzilla integration useful is that this project will be finished before anything happens with Bugzilla so we want to make it actually useful to people.

+1 , that was my original idea. I’ve mentioned the reason why we might want to prefer non-Forgejo for now above… But we’ll discuss this with @manky201 . I agree that this would be better.

7

Good points here. Thanks. Noting down.

I hope we can “steal” some code from Packit that covers various such use cases; however, we may start with something basic and improve it later based on demand/requests.

I would say that if the next step of this is to set up a new dist-git project, we should be close to that structure.

8

I think there is a very strong narrative here with regard to integrating with Packit as much as possible.

My naive, I don’t know enough about anything question is can the goal of this project be implemented as new Packit features? Because if that is true, it substantially derisks the project outcomes.

9

Really good point.

During the student choice period, I wanted all the students to look at reusing/integrating/contributing to what we already have (e.g. Packit, Fedora Review (Service), …

As a Packit member (I am biased, right..:wink: I see ways we can extend Packit to do this. More technically, we can possibly set up a new Packit worker similarly to what we used to do for the source-git initiative and what we now want to do for Packit as a dist-git Fedora CI.
I want Mayank to decide this, but I agree it might be reasonable to do it like this.

10

Yes its a decision the mentee should make.

But lets nudge them a bit.

My pitch as the new FPL, is that the best hope to make sure the work can stay relevant and be something that is used and adapted by fedora packagers after the GSoC project is over is to make this as an addtional featureset for some sort of maintained tooling.

Since Packit’s mandate appears to be in partto make it easy for upstream maintainers to build fedora packages… this sort of automation for package guidelines conformance testing fits right into that. It feels the the same core audience, developers who are not experts in fedora packaging.

11

Hi everyone, thanks for the feedback !

My plan is to reuse code from Packit as much as possible for git forge integration that comes with it.
The challenge I see with Forgejo is the relative immaturity of its libraries and documentation compared to GitHub, so I’ve prioritised building the automation part first rather than focusing heavily on the choice of git forge.

That said, if the choice of git forge matters to our target audience, I will definitely do my best to triage any roadblocks and prioritise accordingly.

12

First of all, that you for working on this! The current package submission process is really dated and is a big obstruction for packaging work and especially onboarding new contributors.

For the Git forge, as a Fedora packager that otherwise uses GitHub both at dayjob and for volunteer open source work and fully appeciate what it offers, for anything that is not just a proof of concept it should be Forgejo. The final, reviewed package will land in Forgejo dist-git, so using a different forge for review seems strange. But if developers’ existing skill and any possible missing features in Forgejo APIs require doing a proof of concept in GitHub, then I guess that would be fine. And we probably have a subset of packagers who would prefer to do everything in GitHub anyhow, and will be just happy if they can move at least part of their Fedora work there, so there is a benefit, too.

Regarding repository setup, in my opinion, in the long run Fedora should definitely move to a model where all dist-git repos are merged to a single monorepo. Then the review process could be implemented as regular pull requests. But that is definitely out of scope here. However, implementing the reviews in a single repo would be a step in that direction, so I support that approach. A future step could be then supporting adding multiple packages in a single pull request, which would significantly improve handling of the case where somebody wants to add a package, but some of its dependencies are also missing from Fedora.

1 Like