Re: rpmautospec by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux