Tag: dist-git

Packit as Fedora dist-git CI: final phase

Hello Fedora Community,

We are back with the final update on the Packit as Fedora dist-git CI change proposal. Our journey to transition Fedora dist-git CI to a Packit-based solution is entering its concluding stage. This final phase marks the transition of Packit-driven CI from an opt-in feature to the default mechanism for all Fedora packages, officially replacing the legacy Fedora CI and Fedora Zuul Tenant on dist-git pull requests.

What we have completed

Over the past several months, we have successfully completed the first three phases of this rollout:

  • Phase 1: Introduced Koji scratch builds.
  • Phase 2: Implemented standard installability checks.
  • Phase 3: Enabled support for user-defined TMT tests via Testing Farm.

Through the opt-in period, we received invaluable feedback from early adopters, allowing us to refine the reporting interface and ensure that re-triggering jobs via PR comments works seamlessly.

Users utilising Zuul CI have been already migrated to using Packit. You can find the details regarding this transition in this discussion thread.

The Final Phase: Transition to Default

We are now moving into the last phase, where we are preparing to switch to the default. After that, you will no longer need to manually add your project to the allowlist. Packit will automatically handle CI for every Fedora package. The tests themselves aren’t changing – Testing Farm still does the heavy lifting.

Timeline & Expectations

Our goal, as previously mentioned, is to complete the switch and enable Packit as the default CI by the end of February 2026. The transition is currently scheduled for February 16, 2026

To ensure a smooth transition, we are currently working on the final configuration of the system. This includes:

  • Opt-out mechanism: While Packit will be the default, an opt-out mechanism will be available for packages with specialised requirements. This will be documented at packit.dev/fedora-ci.
  • Documentation updates: Following the switch, we will also adjust official documentation in other relevant places, such as docs.fedoraproject.org/en-US/ci/, to reflect the new standard.

We will keep you updated via our usual channels in case the target date shifts. You can also check our tasklist in this issue.

How to prepare and provide feedback

You can still opt-in today to test the workflow on your packages and help us catch any edge cases before the final switch.

While we are currently not aware of any user-facing blockers, we encourage you to let us know if you feel there is something we have missed. Our current priority is to provide a matching feature set to the existing solutions. Further enhancements and new features will be discussed and planned once the switch is successfully completed.

We want to thank everyone who has tested the service so far. Your support is what makes this transition possible!

Best,

the Packit team

Packit as Fedora dist-git CI: Phase 1 completed

Hello Fedora Community,

We are excited to share an update on the Packit as Fedora dist-git CI change proposal. This initiative aims to transition Fedora dist-git CI to a Packit-based solution, deprecating Fedora CI and Fedora Zuul Tenant. The change affects the triggering and reporting mechanism for tests but does not alter the tests themselves or the test execution service (Testing Farm). The transition will be gradual, allowing maintainers to try the integration out, provide feedback and catch issues early. You can read more about the benefits and why we are doing this in the proposal.

Continue reading

2024 Git Forge Evaluation

Vol. I – Fedora Council 2024 Hackfest

During the Council’s February 2024 hackfest, we discussed the future of Fedora’s git forge – that is, the platform Fedora uses for version control and tracking for packages, source code, documentation, and more. This topic has been around for quite some time. If you are just coming into this conversation, or would like a refresher, #git-forge-future is a good place to start.

Instead of one huge post, the Fedora Council divided the follow-ups from our hack-fest into a mini-series of posts throughout April that will cover all the topics we discussed and made decisions on. In each post, we will walk through one core topic, and share our discussion and thought process on how we reached our outcomes. The first in this series, because why not start strong 🙂 , is an update on our git forge evaluation. Read on for important information.

Continue reading

2023 Year in Review: Community Platform Engineering (CPE)

This is a summary of the work done on initiatives by the Community Platform Engineering (CPE) Team. Every quarter, the CPE team works together with CentOS Project and Fedora Project community leaders and representatives to choose projects that will be being worked upon in that quarter. The CPE team is then split into multiple smaller sub-teams that will work on the chosen initiatives and day-to-day work that needs to be done. Some of the sub-teams are dedicated to the continuous efforts in the team whilst some are created only for the initiative purposes.

This update is made from infographics and detailed updates. If you want to just see what’s new, check the infographics. If you want more details, continue reading.

Continue reading

Git repo branch name changes

The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities.

The Fedora Project Vision

In line with the Fedora vision, we just completed some changes to the git branch names used on src.fedoraproject.org and elsewhere. We removed the “master” branch for those repositories. For rpms and containers, the default branch is now named “rawhide”, with a symref (alias) of “main”. For flatpaks, “stable” is the default/only branch. The fedpkg tool is updated on all supported released to accommodate this change.

For now module repos are unchanged. We are awaiting improvements in the branch/repo requesting tool to allow module owners to request only those specific named branch streams, since “main” and “rawhide” don’t make sense in that context.

For a list of other impacted repositories, see the change proposal. Of course, other repos have been migrated by their owners independently.

If you have a repo checked out with the master branch still, you can run: git fetch && git switch main

This work is part of a larger effort across the technology industry to be more inclusive in the language we use. See Rich Bowen’s Nest With Fedora keynote, for example. If you encounter any trouble, please file a ticket in the infrastructure issue tracker.

Using source-git to maintain packages in Fedora

Some time ago, we initiated a discussion on the devel list if dist-git is a good place to work. This thread received a great amount of wonderful feedback from you and we are so grateful for every messageit demonstrates the passion of the Fedora community.

If you are not familiar with how packages are being maintained in Fedora or what dist-git is, let me give you a quick summary. Every Fedora package has a dedicated git repository—a dist-git repository. It contains files needed to compile the sources and produce a binary RPM package which you can install on your Fedora Linux system. As an example, you can look at firefox dist-git repository.

This blog post is a followup to the discussion and lays out a concrete plan of what we want to do.

Continue reading

Copyright © 2026 Fedora Community Blog

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Theme by Anders NorenUp ↑