Re: Can we do away with release and changelog bumping?
On Wednesday, July 8, 2020 4:16:34 PM CEST Pavel Raiskup wrote:
On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> problem few months ago.
> It is a koji plugin as well as CLI tool that makes bumping the release
> field and generating changelog problem of Koji,
> instead of package-maintainer. Currently it sits deployed in staging koji,
> so you can give it a test-drive :-)
>
> We hope we can return to it later this year, to have it deployed in prod
> koji.
+1 to what Florian proposes over rpmautospec, though. I think bumping the
release flag is the bare minimal technical change that is needed (except that
bodhi should pre-fill the description by diffs from %changelogs).
Small experiment (few-liner) for copr with "%bid, build system tag":
https://pagure.io/copr/copr/pull-request/1436
Pavel
I before stated my opinion that I don't like the generated
%changelog
idea. Fedora git changelog and `rpm --changelog` are two different
things. Mixing them up will bring more costs than savings (fixing
mistakes in git commit messages retrospectively). Or in other extreme the
ugly `rpm --changelog` output (people don't care they mistakenly provided
broken git commit message).
I think that it would be just enough to allow people to stop producing
`rpm --changelog`s if they think that it so awful amount of work (both
better than more expensive %changelog variant, or ugly variant). Let's
allow packagers to specify something like:
%changelog
* there's no package metadata in changelog
Or in the worst case, automatize:
* there's no package metadata in changelog
- check %_pkgdocdir/fedora-git-changelog file
I'm not saying that we can not see every proposed approach in action as
opt-in. But, IMVHO, we are wasting to much efforts time here that could
be spent on our content served to our users instead (== I mean the overall
%changelog quality).
Pavel
> [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
>
> On Mon, Jul 6, 2020 at 8:22 AM Florian Weimer <fweimer(a)redhat.com> wrote:
>
> > * Björn Persson:
> >
> > > The macro could be defined like this for example:
> > >
> > > %buildtag .%(date +%%s)
> >
> > Using time for synchronization is always a bit iffy.
> >
> > > It would be used in each spec like this:
> > >
> > > Release: 1%{?dist}%{?buildtag}
> >
> > We could put the Koji task ID directly into the %dist tag. We know that
> > this works in principle. If we are worried that the number gets too
> > large, we could subtract the current task ID at the time the fcNN part
> > of the %dist tag changes.
> >
> > The %dist tag is not recorded in the changelog by most packages, so the
> > changelog does not need changing.
> >
> > Thanks,
> > Florian
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > 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@lists.fedoraproject.org
> >
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org