On Sat, Aug 06, 2022 at 11:41:07AM -0400, Neal Gompa wrote: > On Sat, Aug 6, 2022 at 10:33 AM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > On Sat, Aug 06, 2022 at 10:19:19AM -0400, Neal Gompa wrote: > > > 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. > > > > What about adjusting the templates in Fedora to be right for Fedora? > > It doesn't have to an upstream default, a local patch would be enough. > > > > Do we want to assume that people use these less opinionated tools to > make packages for Fedora infrastructure? I know plenty of people > *don't* do that and use tools like rpmdevtools. That said, maybe it > makes sense to make a package of fedora templates and make it possible > for rpmdev-newspec to use them? I think that'd make a lot of sense. Zbyszek _______________________________________________ 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
