On Wed, 13 May 2020 at 22:32, Ken Dreyer ktdreyer@ktdreyer.com wrote:
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, thank you very much for the detailed explanation. I understand now.
I can see three variations on this approach for a per package setup
1) source-git repo, branches per upstream release + dist-git repo with the classic branching (f31, f32, ...) where the branch from source-git is included as a git submodule. You can have patches in source-git which are generic across all distribution release and you can also have a single distro-specific patches in dist-git as classic patch files, spec file would be in dist-git repo
2) the same thing but the source-git repo does not only have branches for upstream releases but also can have a branch <upstream-release>-f32 when I need to patch something specifically for f32, again there is a dist-git repo with a spec file and the submodule for the respective branch (either generic or patched specifically for a certain distro release)
3) there is no dist-git repo with the classic branching structure and there is only source-git with a spec file included. This would require that we would need to define what e.g. f32 means somewhere else by pointing to specific refs in the source git from an f32 definition file. The best for start might be to actually still have some kind of dist-git repo with the classic branches but these would only point to some refs in source-git. I am not sure if there is something in git to enable to have a branch as a pointer to another branch in another repo but at worst we can use a specific file or a submodule again.
Probably there are more variants but I see these three right now. I think variants 1 and 2 where the spec file is kept in dist-git but patches can be in source-git are more within our reach right now (but I might be wrong, variant 3 is also interesting).
clime
- Ken
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org