On Sun, May 10, 2020 at 11:51 PM Petr Pisar <ppisar(a)redhat.com> wrote:
How do you backport fixes? Do apply the fixes directly to dist-git?
Or do you
apply the fixes to a corresponding patches branch that you occur to have
around till needed (e.g. till the hitorical code is supported) for the purpose
It's the latter. We use "git cherry-pick" to pick changes to our
"patches" branch, and then "rdopkg patch" writes those as .patch
and PatchXXX entries in our .spec file in the corresponding dist-git
At a general level, a typical Fedora packager performs three kinds of
operations in dist-git:
1) Rebasing to a new upstream version (eg. bumping the "Version" field
in httpd.spec from 2.4.43 to 2.4.44)
2) Fixing something in RPM packaging itself (eg. removing "Groups"
from httpd.spec file, fixing %check, etc)
3) Patching the source code (eg. cherry-picking a patch from
The current implementation of dist-git allows everyone and anyone to
very clearly audit all three of these actions. This kind of
transparency is really important to Fedora's goal of building a
trusted operating system.
Upstream projects do ninja edits all the time. It's just too
convenient to force-push or move Git tags, etc. Sometimes upstream
authors have valid reasons for doing that kind of thing, but
downstream we have different incentives. The fact that we have strong
history preservation guarantees is one of the reasons I use Fedora.
rdopkg has sub-commands to automate each of the three categories
above. For #3 (patching), in RH Ceph Storage we run the "rdopkg patch"
operations in Jenkins, because that is the most common operation by
I'm watching packit, and I am interested to try it out one day to
understand more about how it compares. I'm still not clear from this
thread what source-git is, or how it compares technically to what
we're doing with Ceph and OpenStack.