On Sat, Aug 6, 2022 at 10:11 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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 As the maintainer of rpmdevtools, I will probably not accept changes upstream to change to rpmautospec in the templates, since rpmautospec doesn't work outside of Fedora and there's been no advocacy to make rpmautospec a cross-distro tool. If someone wants to champion rpmautospec as a cross-distro tool, then I will reconsider. -- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue