On Tue, May 12, 2020 at 6:20 PM clime clime@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 NVR?
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: https://fedorapeople.org/cgit/ktdreyer/public_git/python-jenkins-job-builder...
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 like that.
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.
- Ken