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 message—it 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.

So, what’s source-git? It’s a git repository which uses the upstream git layout instead of the dist-git layout. The main benefit is to see and work in a git tree which resembles the RPM %prep phase; this way it’s much easier to backport patches from upstream or see how the upstream project looks. If you are okay with the dist-git workflow and would not find this useful, it’s perfectly fine and this technology may not be for you (though you may still give a try!). You can read more about source-git here.

In the first iteration, we’d love to provide the source-git repos to you, Fedora package maintainers, on-demand. We have full support for GitHub right now and would love to set it up for pagure.io as well. The way it would work is that you’d reach out to us and we’d set up the repositories for you and provide guidance. What would you get?

  • The preferred workflow is centred around pull requests against a source-git repository and utilizes continuous integration heavily
  • Once a source-git PR is opened, a corresponding dist-git PR is opened as well. All test results are mirrored to the source-git PR.
  • Once a PR is merged into a source-git repository, the corresponding dist-git PR is merged as well, and vice versa: if a source-git PR is discarded, the downstream PR is discarded as well.
  • For every commit pushed to a dist-git repo, automation proposes respective commit to the source-git repo as well. Nevertheless, it’s always possible, with a single command, to get both repositories in sync.

As I wrote above, this blog post proposes a plan—most of the items I just described are not implemented, yet.

As an example, you can check an example source-git repository and a respective downstream PR created by packit

Did I say packit? That’s the underlying tooling we’d be using to achieve all of this. It’s the implementation for working with source-git repositories.

Please bear in mind that all of this is meant to be a prototype and a subject for change. We do welcome all your feedback!

Happy hacking!
Tomas on behalf of the packit team.