This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 25 Aug – 29 Aug 2025
Continue readingThis is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 18 Aug – 22 Aug 2025
Continue readingHi, I am Mayank Singh, welcome back to this blog series on the progress of the new package submission prototype, if you aren’t familiar with the project, feel free to check out the previous blogpost here.
As Forgejo is expected to become the git forge for Fedora in future and based on community discussions. I thought it did be great to support Forgejo in this project.
packit-service supports both GitLab and GitHub thanks to OGR library. It provides a unified interface for interacting with git forges.
The library has a good support for GitHub and GitLab features but the Forgejo integration is still not quite on par with them, few important functions like adding comments and reactions are still missing.
I worked on adding the support for the necessary parts so that packit-service can work with Forgejo.
There are few bugs related to serialization in the code, which I plan to fix this week.
I’ve added a simple handler to read from a new Pull Request and its description to parse packit commands. This allows users to trigger a build for a new package without needing a packit configuration file in the repository.
For example, adding this line the PR description will trigger a new build for this particular package name.
/packit copr-build package_name: <libexample>
The system dynamically constructs a minimal package config and feeds it into Packit’s internal build logic. Test jobs are expected to work as well, although this is yet to be fully verified.
The current implementation is a quick prototype that reuses as much of the existing packit-service logic as possible. There’s still more work to be done around building the full package context.
My mentor has also shared feedback suggesting a cleaner approach, which I’ll be iterating on in the next phase.
Thanks for reading and stay tuned for more next week.
This week in the project involved bug fixes, integration cleanup and small improvements.
A key function required for the Forgejo integration which is used to fetch files from repositories was broken in the current Fedora 42 release due to an upstream bug in Forgejo’s OpenAPI spec. While the bug is already fixed in newer versions, it couldn’t be backported cleanly due to dependency constraints.
To move forward, I upgraded the service to run on Fedora Rawhide. However, Rawhide had its own quirks, the celery package was broken. To work around this, I installed celery directly from PyPI instead, which resolved the issue for now.
There were also several issues related to how data was being passed between the celery tasks. In particular, raw comment objects from Forgejo events were being passed around, which are not JSON-serializable and caused failures. With help from my mentor, added fixes in the logic to ignore the problematic object from being included in the payload.
Enabled the `fedora-review` tool for all COPR builds in the codebase by monkey-patching the API call to enable fedora-review, which is not available directly otherwise from the packit API. This allows us to get a list of tasks and requirements for Fedora packaging compliance for the corresponding build of the package.
As of now, COPR builds and testing of the builds work. I started working on status reporting, it’s still rough, and I attempted to get comments working, but I’ll need to add more support in the OGR library to implement commit status properly.
packit-serviceAs part of my Outreachy internship with the Fedora Project, I’m building an API to modernize how Fedora plans its release cycles.
With the help of my mentor Tomáš Hrčka, the goal is to replace the current XML-heavy system currently on pagure.io with something flexible, easy to use, and well-structured.
Explore the source code on Codeberg: Fedora Release Schedule Planner.
Fedora’s current release planning tools rely on manual XML editing, which is challenging for newcomers and difficult to scale. This project aims to:
These changes already make onboarding contributors easier and improve testability.
I’m excited about these upcoming milestones:
My biggest challenge and opportunity is simultaneously learning new backend technologies like FastAPI and OpenID Connect for authorization, along with techniques to improve developer onboarding. Though the learning curve is steep, my mentor’s continuous guidance on the Fedora infrastructure, career development and general advice makes it manageable.
This internship has been an incredible learning experience. I’m gaining hands-on exposure to backend architecture, continuous integration practices, and open-source collaboration. More importantly, the chance to build something lasting for Fedora makes the work genuinely rewarding.
There’s a lot left to tackle, and I’m looking forward to pushing it further.
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 04 Aug – 08 Aug 2025
Continue readingJuly is already behind us – time really flies when you’re learning and growing! I’m happy to share what I’ve been up to this month as a Fedora DEI Outreachy intern.
To be honest, I feel like I’m learning more and more about open source every week. This month was a mix of video editing, working on event checklists, helping with fun Fedora activities, and doing prep work for community outreach.
Continue readingThis is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 28th July – 01st August, 2025
Continue readingThis is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 21st – 25th July 2025
Continue readingThis is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 14 July – 18 July 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
Copyright © 2026 Fedora Community Blog
This work is licensed under a Creative Commons Attribution 4.0 International License.
Theme by Anders Noren — Up ↑
Recent Comments