On Tue, May 12, 2020 at 6:20 PM clime <clime(a)fedoraproject.org> wrote:
When you do rdopkg new-version and you are asked to force push, is
also the current master-patches HEAD tagged with the current package
It's something that I have to do before I run "new-version". Here's
the command I ran today:
$ rdopkg tag-patches --push
And rdopkg performed the following commands for me:
git tag python-jenkins-job-builder-3.2.0-1 master-patches
git push patches python-jenkins-job-builder-3.2.0-1
You can see the new tag here:
rdopkg read the current NVR, tagged the tip of the master-patches
branch for me, and pushed that tag to the patches remote.
Somewhere I was expecting to see a lot of NVR tags for past sate of
master-patches (i assume, you could have also f32-patches,
f31-patches, epel8-patches, ... ?) but I don't see those tags :) that
would form the mentioned "history of histories".
You're correct, rdopkg supports branch names like "f32-patches",
"f31-patches", and "epel8-patches". In my case I only needed to patch
Rawhide, so I created "master-patches" there.
You're right that I didn't create a ton of NVR tags. This package is a
super trivial example where I only started using this model to fix a
FTBFS, so I did not tag every NVR. The reason I did this was because
there are only a few patches and I did not expect to keep them in
Fedora very long, because I can easily rebase Rawhide to 3.3.0 soon,
and the upstream authors were going to ship 3.3.0 soon. When we ship
an unpatched upstream release, there's less utility to tagging the NVR
For the ceph package in RH Ceph Storage, we've tagged over three
hundred NVRs with this system. We could probably go back and check
which old builds koji-gc has deleted, and then delete those Git tags
as well, if we want to clean up the ones that we never shipped.