rpmautospec by default

[Zbigniew Jędrzejewski-Szmek]

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/#_exampl...
    https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_empty_...
    ...
[6]
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutori...
[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