From Fedora Project Wiki
(Add Don as a member)
Line 68: Line 68:
* [[User:Jpopelka|Jiri Popelka]]
* [[User:Jpopelka|Jiri Popelka]]
* [[User:scoady|Stephen Coady]]
* [[User:scoady|Stephen Coady]]
* Don Zickus (representing [[|Fedora Always Ready Kernel]])
== Status ==
== Status ==

Revision as of 14:56, 7 April 2021

This SIG is a work in progress and will be announced properly once we're ready, stay tuned.


  • Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed).
  • Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows MUST NOT be dirupted.
  • Maintainers HAVE TO be able to step in for automation and replace some of its actions if needed. The automation NEEDS TO handle such situation.


Our main goal is build a Minimal Viable Product during the Fedora 35 development cycle.


  • Source git repos can be easily created, set up and this is well-documented.
  • The workflow is defined well and it's clear where the repositories are hosted.
  • Source-git content is synchronized into dist-git via dist-git pull requests.
  • Specfile changes are synchronized back to the source-git repo from dist-git.

Benefits to Fedora

  • Downstream patches are tracked as git commits. This way it's easier to backport or cherry-pick changes from the upstream and rebase the patches when a new upstream release happens.
  • Patch files are handled by automation which makes the job of maintainers easier.
  • It should be easier to onboard more maintainers in Fedora community since the workflow would be closer to the way the contributors work in the upstream project.



1st meeting agenda

  • Agree on communication channels
  • Define how work is going to be tracked

Follow-up work

Once the MVP is implemented, we can start building more automated workflow on top of the MVP.

  1. Set up a source-git repository manually on a packit-supported platform (,
    • This includes creating a specific branch and setting up jobs for packit-service to handle events.
    • CI can (and should) be set up (such as Testing Farm).
  2. Anyone in the community is able to interact with this repository the same way with any other open-source project.
  3. Packit-service can accept events when a new upstream release is done (via Upstream Release Monitoring).
  4. Packit-service creates a pull request which contains changes to bring the new release to Rawhide.
    • A dist-git PR is created in parallel. Downstream checks are synchronized to the source-git PR.
  5. The owner of the source-git repository reviews and updates the pull request as needed.
  6. Once approved, dist-git PR is merged first and packit-service triggers a build in Rawhide. If the build passes, source-git PR is merged as well. If the build fails, source-git PR is updated a new dist-git PR is created and doing the cycle of this step again.



We have been in a planning stage of the SIG: bringing interested people together to flesh out the who, what, where, when, and how.


TBD - will be defined during our first meeting.

In the meantime you can reach out to the team on #packit at Freenode IRC.

Important links