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(a)in.waw.pl> 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(a)in.waw.pl> 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