On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
Questionnaire right at the beginning, so if you tl;dr, you don't
miss it:
https://forms.gle/Jgr13vtRkiUwLb6W6
This is no change proposal but rather a result of my long-term curiosity
around the $Subject problem. I hope I marked the results public so the
results are visible to anyone.
------------------
ATM, I know of at least those serious attempts to "automatize" the
%changelog maintenance and Release auto-bumping: [1, 2 and 3].
All those proposals are pretty complicated (I know, this is POV
statement), but some of them require significant changes in build systems
(like allowing the build system to back-push the generated stuff, building
the code variant which is not yet committed, so security problems, etc.).
It's not easy to decide the preferred variant... :-) But let me feed
the xkcd 927 :-) .... here is another. Call it e.g. the "Trivial" (or
compromise) variant.
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}"
... and let the build-system to put there an artificial (but increasing for
subsequent build IDs) value.
When looking into rpmautospec this was one of the idea we thought about. There
are a few downsides to it that made us go in a different direction:
- Relies on the build system and cannot be emulated locally (without access to
it)
- Conflicts wit the minor release bump field of the versioning schema:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_mo...
IIRC the first one was the one that blocked this idea for us as it was mentioned
on the list that people want to be able to build their RPM locally as close as
possible from what the build system does.
The %changelog problem
======================
IMO, all the burnouts and wasted time around %changelog is caused by those
things:
a) we misinterpret what git-log is for, and what %chagnelog is for, but
b) we are still forced to properly maintain the %changelog, and
c) we have to duplicate %changelog in Bodhi
Well, the bodhi update description should likely be the one most different from
the other two.
[..]
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>
One of our requirement when we looked into this for rpmautospec was that the
changelog should be accessible on a machine without internet (think: network
stack is busted, I want to check what changed in the rpm of that stack).
So while tempting this wouldn't fit.
Pierre