Disclaimer: I'm part of the team who worked on rpmautospec, i.e. I'm
obviously biased and will view everything through that lens. ;)
On Thu, 2020-08-13 at 15:08 +0200, Pavel Raiskup wrote:
> Release tag problem/proposal
> ============================
>
> Let's stop requiring Release bumps for each build. And let's put an
> additional tag into Release, like proposed in [4]:
>
> "Release: 1%{?dist}%{?buildtag}"
We discussed something like this for rpmautospec but went with "more
complicated" because that lets us do two things:
- Give maintainers a parametrized macro which makes it easier to
package pre-/post-/snapshot-releases. This use case is one of the more
complicated ways to (ab)use the release field and I've time and again
seen it done wrongly. Getting it right in one place and absolving
maintainers from dealing with the complexity involved seemed like a
good thing to have.
- Take history, i.e. existing builds in the affected and other Fedora
releases, into account. For one, this allows us to ensure a clean
update path (AIUI, this is still required by the packaging guidelines)
about as good as manual maintenance would. For another, it makes opting
in easy: just put in the macro and you're done, no need to keep the
bumped release and remember to reset it when the next version bump
happens.
> The %changelog problem
> ======================
...
> Bringing in the automation into our processes will either (a) require
> a
> **lot more pedantic maintainers** (even though we don't want to
> complicate
> our life) or (b) mean a decrease of quality of %changelog(s). The
> (a) is
> OK, as long as people opt-in. We have to admit that there's (b).
I disagree with both points.
In my experience, the %changelog contents are just a subset of what
ends up in the SCM commit log(*). Mistakes happen of course (some
mistakes shouldn't, e.g. wrongly formatted dates), but they can be
corrected after the fact, with or without automation.
Mind that -- beyond our original prototype -- we surely want a way to
let people directly flag a commit not to be used in the changelog, e.g.
for the "oops, forgot to upload the tarball" situations, where having
to let e.g. fedpkg update the external changelog file and edit that is
somewhat over the top.
My take is that whether or not mistakes get fixed largely depends on
how the individual maintainer feels, regardless of if the changelog is
manually or automatically maintained.
(*): If not, i.e. if the %changelog of your package is only spuriously
related to what's in git commit logs, then changelog automation won't
help you. One of the reasons why it's opt-in.
> Is it acceptable in the Fedora community to relax the rules around
> %changelog,
> and decrease its quality (a bit, or a lot)? Do we think that
> %changelog is no
> more worth the all manual trouble? If we tend to answer yes, maybe
> we should
> rather go with something trivial as this:
>
> %changelog
> * This package doesn't provide changelog metadata, check it online
> https://src.fedoraproject.org/rpms/<name>/commits/<last_commit>
>
> Such %changelog has a very similar level of quality as all the
> generated
> approaches, and we don't have to complicate our lives (or
> buildsystem).
Downside is, it can't be accessed offline _and_ you have to wade
through all the "fixed this and that mistake" cruft.
> Alternatively, we can teach build systems to upload the git-log file
> somewhere, or even extremely drop the changelog entirely (and only
> reference the upstream changelog in %doc payload).
Not sure what you mean by "upstream changelog", if it's the one
upstream that doesn't (usually can't) cover packaging changes like
"split off bananas into its own subpackage", then I'm strictly against
it. That information is valuable.
> Side question: Is it really useful to put "Rebuilt for
> https://fedoraproject.org/wiki/Fedora_XX_Mass_Rebuild"; into
> changelogs?
Our idea was that these entries would go away with %changelog
automation, as mass rebuilds could simply build again from the HEAD of
the branch.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
_______________________________________________
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
