Hi everyone, I’m Mayank Singh, and I’ve been working on a GSoC 2025 project aimed at simplifying the packaging process in Fedora.
I have been working on making an implementation of the new package review process, where everything happens in one place around git. Instead of switching between Bugzilla tickets, for hosting the source rpm and logs. Instead new contributors can review their packages through pull requests.
Let’s dive into a brief comparison between the current Bugzilla process and the new one.
The current Bugzilla process
If you want a package that is not available in Fedora repositories yet, the process looks something like:
- Package Recipe: start by writing a
.specfile, which declares your package sources and instructions on building it. - Build: the same specfile is then used to build a Source RPM.
- Upload: upload the Source RPM and specfile to a file host or a place like fedorapeople.
- New Ticket: Now, start a new bugzilla ticket with the SRPM url and Spec url along with the description of the package.
- Fedora-review-service: This service builds your package in COPR from the provided SRPM and specfile URL, runs fedora-review after a successful build to report compliance.
- Review Cycle: A reviewer comes along, provides feedback, make changes, upload again. This creates a tedious, repetitive cycle for every minor change.
This process isn’t reliable, it forces developers to constantly juggle multiple tools and tabs. This creates a fragmented and disjointed experience.
The new process
We try to solve this problem by trying to focus the workflow around git. A tool developers already use daily. The process is made much simpler in these steps:
- Fork the central package review repository on forgejo.
- Commit your .spec files and patches.
- Start a new Pull Request.

The service takes care of the rest for assisting in the review process.
Once the Pull Request is open, the following automated actions are triggered to assist the review:




Checking the latest entry here, we can find the Testing Farm run and inspect the logs to trace the cause of failure.

The checks failed due to a broken package and its dependencies.
- Automatic Build: The service clones your changes into a COPR build environment and builds the package.
- Direct Feedback: After a successful build, the
fedora-reviewtool runs, and its formatted output is posted directly as a comment in the pull request discussion. - Testing: The service runs installability and
rpmlintchecks using Testing Farm. - Commit Status Updates: The status of the COPR build and all tests is reported back directly to the pull request via commit statuses (the green checkmarks or red crosses).
If a change is needed, one can just push a new commit and the service takes care of building and testing now.
Check out the service here: review
Under the Hood
The service is based on the packit-service codebase to handle COPR builds, Testing Farm integration, and orchestration of the actions described above with forgejo support.
Repo link: packit/avant
Future Scope
Looking ahead, this workflow can be extended to transfer the packages into dist-git after approval of the package.
Big thanks to my mentor and Fedora community for guidance throughout the GSoC timeline.
Feedback’s appreciated ! Thank you.


What happens after a package is approved?
Thanks for the update. Here’s a quick question:
How do multiple package reviews in parallel from the same user work? Can they depend on each other too? These are common usage workflows when one is working with an ecosystem where multiple packages/dependencies need to be packaged.
(I don’t think forges like pagure/github allow users to have multiple forks of the same project—does forgejo?)
Also: this one repo will have many many forks:
Once the package is approved, the pull request is closed, for the process after that like the transfer to dist-git allocation and uploads, the project did not cover that part yet.
It’s something that needs to be discussed, maybe could be more feasible with forgejo migration of Fedora.
Good point, forgejo I don’t think supports multiple fork from the same user like others.
As for handling multiple package reviews in parallel, it can be done using separate branches within the same repository and opening individual pull requests for each package.
As for inter dependent packages, It does not currently implement that but I believe should be possible to support. I’m open to suggestions regarding this part