Getting a package into Fedora is more than writing a spec file. There’s a review queue, a sponsorship process, and a contribution pipeline that can feel opaque to newcomers. Episode 055 is a deep dive into how that pipeline actually works, and what one contributor has been building to fix the parts that frustrate him most.
My guest is Jakub Kadlcik, known in the Fedora community as FrostyX. He is a Red Hat software engineer in Czech Republic who works on Copr, Fedora’s build system for distributing RPM packages outside the official repositories. Copr is one of those if-you-know-you-know tools: it lets developers build and host packages for any Fedora version and architecture without any formal review process, making it the natural starting point for anyone working their way toward official inclusion.
The most interesting part of the conversation is Jakub’s Fedora Review Service. The package review queue has sat in the hundreds for over a decade, and Jakub traced a lot of that backlog to something avoidable: the first round of every review was almost always trivial formatting issues that an automated tool would catch instantly. So he built a service that listens to Bugzilla, builds packages in Copr automatically, runs the Fedora review tool, and posts the results back to the ticket before a human reviewer ever looks at it. Simple, no AI, just automation doing exactly what automation should do.
We also got into the sponsorship bottleneck for first-time contributors, a website Jakub built to make packager sponsors findable, his proposal for per-commit package checks, and what the migration of src.fedoraproject.org to Forgejo might finally make possible for the packaging workflow. We spent probably three minutes trying to agree on how to pronounce Forgejo. No resolution was reached.
Jakub also talked about his FrostyX Unscripted YouTube channel, which started partly as English speaking practice and partly as a deliberate attempt to fight impostor syndrome by showing what real development work actually looks like, typos, wrong ideas, and all.
This is exactly the kind of episode I love hosting: a contributor who identified a real friction point, built something practical to fix it, and can explain the whole system clearly without oversimplifying it.