On Wed, 13 May 2020 at 22:32, Ken Dreyer <ktdreyer@xxxxxxxxxxxx> wrote: > > On Tue, May 12, 2020 at 6:20 PM clime <clime@xxxxxxxxxxxxxxxxx> 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.git/log/?h=master-patches > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
