Le lundi 06 juillet 2020 à 10:19 +0200, Adam Saleh a écrit : > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve > this problem few months ago. > It is a koji plugin as well as CLI tool that makes bumping the > release field and generating changelog problem of Koji, > instead of package-maintainer. Currently it sits deployed in staging > koji, so you can give it a test-drive :-) > > We hope we can return to it later this year, to have it deployed in > prod koji. > > [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html I think it is good to have alternative implementations that show what the real consequences and costs of doing something one way or another are. The abovementioned implementation is tied to koji and will never work outside koji, and involves quite a lot of spec munging (that may work or not, I suspect it won’t work so well on my spec files for example). And it takes a lot of moving pieces to do so. Because the build state exists in koji only, there is no need to commit back to git. Conversely, this is what makes it a koji-only solution that does not export well to other build systems. My implementation is much simpler (6 files changed. 179 lines added. 5 lines removed) https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump However it relies on another redhat-rpm-config change which is definitely not simple (30 files changed. 2163 lines added. 619 lines removed). Though probably still quite less than the whole of rpmautospec + rpmautospec macros + koji plugin https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/213995c8371837f3689c0d053ed055c25de287c9?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump The other redhat-rpm-config change was done for other reasons, and contains code to address totally different needs, and I will need it whether the bumping change is done or not (but, I’m sure the rpmautospec guys will state a lot of their code was also written for other reasons). I suspect my implementation wins on genericity and on the other features it unlocks within spec files, while the rpmautospec implementation wins if you want to keep things within a little team of Fedora infra people. I’d call my implementation more elegant, because it tries to fix things within spec files first, and uses the fixes to make it easier to implement higher level features. While the rpmautospec solutions tries to take spec files as they are and force a high level feature over and from outside a packager spec file. But I will be the first to admit I am biaised. Had I not been convinced it was the right approach, I would not have invested the coding time in the first place. Regards, -- Nicolas Mailhot _______________________________________________ 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
