Hi everyone,
During the FESCo panel during Nest one of the conclusions was that FESCo should take a more proactive role in pushing changes in Fedora. We talked about enabling koschei by default and other similar things. Here's my attempt to start with something I hope will be somewhat easier:
** Let's make %autorelease + %autochangelog the default approach in Fedora packaging **
I think we should follow the Change process for this, to raise visibility and reach all interested parties. I'll file such a Change later [*], based on the initial feedback here. Jump to the end to see the proposed Scope.
** Why? **
The original motivation for %autorelease + %autochangelog was to save some typing for packagers. In Fedora all packaging work happens in dist-git, so every change would need to be described twice: once in the %changelog entry and a second time in the git commit message.
A second motivation is to ease cherry-picking commits between branches. The Release field and the %changelog sections would often be the only source of a trivial conflict when merging branches or when backporting a commit from rawhide to a release branch.
A third motivation to improve the workflow for pull requests. (This is a variant of the previous item, but worth mentioning on its own.) If a pull request is not merged right away, the Release value used may in the meantime be taken by a different update, and the %changelog text may conflict.
A fourth motivation that has become more relevant is rust2rpm and other automatic packaging workflows. As described e.g. in Fabio's Rust Packaging Tutorial [2], one may want to regenerate the spec file for new rust2rpm version or when the package is updated. With the traditional %changelog section, old entries need to be copied over, but with %autochangelog we get continuity without any additional work.
** Why now? **
rpmautospec has been slowly improving over time. With the 0.2.6 release, it is ready for general use with all packages.
** What exactly is being proposed? **
rpmautospec [1], i.e. 'Release:%autorelease' and '%changelog\n%autochangelog' becomes the recommended workflow for new packages.
All documentation is updated to describe this workflow.
Converting existing packages is recommended.
The legacy workflow is still supported and there is no plan to disallow or discourage it.
No mass-conversion of existing packages is planned. (I think it'd be reasonable to do this at some point in the future, but this is explicitly out-of-scope for now.)
** Scope **
1. implement changelog skipping [3, 4] 2. any other rpmautospec issues? (I don't see other big issues, but if people consider something important, we could treat them as blockers.) 2. release and deploy new rpmautospec version 3. adjust packaging guidelines [5] 4. adjust tutorials [6, any other?] 6. adjust fedora-review ([7], but that's the wrong place) 7. adjust rust2rpm default [DONE in v19, 8] 8. other packaging tools? (do we use an automatic converter for pypi?) 9. adjust rpmdevtools templates 9b. adjust emacs-mode 10. make it easier for packagers to know what changelog version is *deployed* in koji [9]
So… I think we should do this. Please say that you agree ;) Is something missing from the scope?
[1] https://docs.pagure.org/fedora-infra.rpmautospec/ [2] https://decathorpe.fedorapeople.org/flock2022/rust-tutorial-nest-2022.pdf [3] https://pagure.io/fedora-infra/rpmautospec/issue/206 [4] https://pagure.io/fedora-infra/rpmautospec/pull-request/259 [5] https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_example_s... https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_empty_spe... ... [6] https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_... [7] https://pagure.io/fedora-infra/rpmautospec/issue/238 [8] https://pagure.io/fedora-rust/rust2rpm/c/22804aeab0 [9] https://pagure.io/fedora-infra/rpmautospec/issue/260
[*] The Change process doesn't fit very well because this will not be tied to any release of Fedora, but it's good enough. Similarly as for the change to SPDX that's happening now.
Zbyszek