Hello,
in Packit, we automatically submit dist-git pull requests for new upstream versions.
During the last few years, there were various opinions about changelog handling and we've already changed the default behaviour based on user feedback (and now are regretting it..;). Currently, we are thinking about another change -- so, it's probably time to seek your advice on what should be the suggested/default behaviour and how to help maintainers fulfil Fedora Packaging Guidelines and provide meaningful changelogs.
With more and more people using Packit, it's also a nice opportunity to unify and improve the changelog content since we can influence the behaviour of many packages in one place. (Side note: we can leverage this feature more if needed.)
Current state:
New release ${PACKIT_PROJECT_VERSION}
Related notes: There is an issue about allowing people to change the proposed changelog more easily (currently, one needs to do it locally and amend the pull request). There is also a related issue about handling changelog lenght.
So, these are our questions: What do you suggest to do by default? Is there any approach (e.g. autochangelog) we should suggest/market/warn-about/...?
Thank you in advance for any advice!
rpmautospec has been the recommended approach for changelogs since Fedora 38 (i.e. on all current branches of Fedora): https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
I usually use commit messages like "Update to version 1.2.3; Fixes RHBZ#1234567", which also causes bodhi to close the associated bug.
Thank you for making changes here - putting upstream changelog or release notes into the package changelog has always been wrong.
My opinion is that the recommendation should be:
Use %autochangelog, and configure the commit message as:
Update to version 1.2.3 - Fixes: rhbz#1234567
actions: commit-message: - bash -c 'echo "Update to ${PACKIT_PROJECT_VERSION}"' # git requires a newline between the commit title and the body, hence the leading "\n" - bash -c '[ -z "$PACKIT_RESOLVED_BUGS" ] || echo' - > bash -c '[ -z "$PACKIT_RESOLVED_BUGS" ] || echo ${PACKIT_RESOLVED_BUGS} | tr " " "\n" | sed "s/^/- Fixes: /"'
(This should be easier. Packagers should not be expected to copy-paste this horrible YAML bash-tr-sed blob between packages.)
Packages that choose not to use %autochangelog should use changelogs like:
- Update to version 1.2.3 - Fixes: rhbz#1234567
Which can probably be achieved similarily to he commit message above.
@decathorpe , @churchyard , thanks for the responses!
I think it makes a lot of sense and justifies even a change of default behaviour.
I've changed the issue by Miro to change the default behaviour.
Regarding the commit message, it now works as you've described (example). That ugly commit-messageaction should not be needed anymore.
commit-message
Last question -- is there anything we can do to promote autochangelog more than in the documentation? A few wild ideas (without thinking too much about implementation):
Thanks! František
rpmautospec has been the recommended approach for changelogs since Fedora 38 ... Use %autochangelog
This is great when the maintainer uses it. But if he does not - for his own reasons - we have to honor their decision and use the old %changelog format.
I would not recommend automatically switching to rpmautospec. It can lead to unintended results in some edge cases, so it should only ever happen when the maintainer decides to (and can verify the result is correct).
For clarification, I was not suggesting packit should make the decision and/or conversion to %autorelease.
I merely meant that the default recommendation should follow the packaging guidelines which recommend %autorelease as well. I also included a recommendation for packages that don't use it.
@decathorpe @churchyard
Yes, I got it and agree we should not do the conversion for the user. We'll stick with suggesting the autorelease in the documentation.
Thanks a lot for the comments. (We know what to do so I am closing the issue, but let me know if there is anything else worth covering.)
Metadata Update from @lachmanfrantisek: - Issue close_status updated to: accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.