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.
Or alternatively, teach the build-system to enhance
%dist in a similar fashion, as suggested in [5].
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
Simply put, IMO, there's no easy way to transform git-log to %changelog,
because those logs have different audiences (package users, vs. package
maintainers).
As I claimed somewhere before, as opt-in, I really don't see any problem
in allowing - as opt-in - any kind of the proposed automation. Even all
of them. ... so the questionnaire allows us to vote for (or against) all of
them.
But any such automation isn't for free ... people do typos in changelog,
and tend to fix them quickly by follow-up commits. Fixing changelog is
now a matter of just another commit, but with the automation - we have to
have proper syntax/semantics for fixes (and fixes for fixes), have some
commit filtering mechanisms, etc. And maintainers need to understand
them.. Take a look at GNU's gitlog-to-changelog, and example of use [6]
(fwiw, none of [1,2,3] attempted to re-use that logic).
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).
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).
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).
Side question: Is it really useful to put "Rebuilt for
https://fedoraproject.org/wiki/Fedora_XX_Mass_Rebuild"; into changelogs?
[1] https://github.com/rpm-software-management/mock/pull/526
[2] https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
[3] https://docs.pagure.org/Fedora-Infra.rpmautospec/index.html
[4] https://lists.fedorahosted.org/archives/list/copr-devel@xxxxxxxxxxxxxxxxxxxxxx/thread/S7EXSR4UX4KQO32PYDBNQHVPAWFFVGWK/
[5] https://lists.fedorahosted.org/archives/list/copr-devel@xxxxxxxxxxxxxxxxxxxxxx/message/LJYXURA5RZFKD47LBDNEGPLTKHYJNX4R/
[6] https://git.savannah.gnu.org/cgit/libtool.git/tree/Makefile.am#n553
Ideas?
Pavel
_______________________________________________
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
