Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann' Mierzejewski a écrit : Hi, > That's not detailed at all. You should provide at least one example > here (or a direct link to one somewhere else on the wiki). Thank you for your attention and kind review. yes the wiki page was completely insufficient, I did it at the last minute to honor deadlines. Please check if it is ok for you now. Anyway here are some answers I added to the wiki > > What's "autobumping" here The change will make packages that use the %auto_<call> redhat-rpm- config macros auto-bump and auto-changelog at the rpm level, in an infrastructure-independent way. The %auto_<call> framework is proposed in https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs In that context, auto-bumping means that a SRPM, produced in any compatible build system (that is, any build system that does not inhibit low-level rpmbuild behaviour), will rebuild by default to a release higher, than the last build release, in the next build system it is imported into, without any manual change to the SRPM source files. Auto-changelog means that the build event will also be traced in the rpm changelog (again, without any manual change). > and how is it better than rpmdev-bumpsec? Unlike rpmdev-bumpsec, the feature is automatic. It does not require explicit human action. Releases get bumped even if the human forgot a particular release has already been built. It does not rely on an external tool, nor requires this external tool to be able to parse a spec file (which can be difficult for heavily automated spec files like the ones that take advantage of %auto<call> macros). A rebuild does not touch the spec file at all. That means, the spec files changes tracked by your favorite scm, will show only spec logic changes, without drowning those in no-logic-change build events. > [...] > > == How To Test == > > > > A redhat-rpm-config packages with the changes and some example > > packages are available in > > > > https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/ > > A diff with changes The current code state is visible in https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/commits/forge-with-patches It’s one small commit on top of the huge change queued in: https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/95 That PR can still evolve based on feedback and testing. Therefore, I can’t promise that the auto-bumping logic will always apply directly, just that it will look more or less this way after rebasing. I do not rebase it on every change to the other PR. This is very young code, there are probably lots of easy things to tidy up in there. However it works. > > Why is a separate "rpm-changelog.txt" file with manually maintained > changelog better than current manually maintained changelog inside > .spec? This change does not separates the changelog. The separation is already done in https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs that this change builds upon Without separation, we would lose the benefit of auto-bumping at the SCM level, since no-logic-change rebuilds would still result in a spec file change. Separation makes automation a lot easier since adding to the changelog is just pre-pending some lines, and does not require any knowledge of rpm syntax. Auto-bumping will add a "* date name evr" line on the next rebuild, so changelog additions can limit themselves to plain text descriptions of new changes at the top of the existing file. Separation is a requirement for auto-changelog bumping at the rpm level. Once rpmbuilt is lauched, it can not modify the processed spec file. Therefore making the changelog modifiable by the build process requires splitting it out of the spec file first. > How about using git commit log for changelog instead? This is a low level change that does not depend on any specific infrastructure, git included. It works directly at the rpm level. An infrastructure that uses git, can feed git commit events to the detached changelog file, using dumb or elaborate git commit hooks, and any other method it wants to implement. The auto-bump logic does not care, it will use the detached changelog file in the state it exists at the start of the build process. Because the logic catches all rebuilds, regular manual trimming of the lines that add no value is recommended. > [...] > > To get beautiful changelogs, you also need to add > > > > <pre> > > %buildsys_name Your name > > %buildsys_email Your email > > </pre> > > > > in ~/.rpmmacros > > What about having one macro called %buildsys_packager instead of two? > You're always using them together, anyway. It'd be similar to the > existing %packager macro, too. This is certainly doable and will simplify the code. Therefore, I will do it. I was formatted by the way name and email are separated in .gitconfig Please ask any other technical question you may have, they are helping me to make this Fedora feature better Reagards, -- Nicolas Mailhot _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
