Dne 12. 01. 20 v 22:56 Miro Hrončok napsal(a):
On 10. 01. 20 17:36, Pierre-Yves Chibon wrote:
> Is there a different approach, e.g. by using towncrier[1] or something
> comparable, to track changes outside the spec file?
Is the idea of using annotated git tags abandoned altogether?
We could even create a tool that would "prefill" a template with all
commit messages since the latest annotated tag.
So you would do:
- commit, commit, commit (optional pushes)
- fedpkg release
- edit the message, inspect the e:v-r, be able to abort if I don't
like it
- fedpkg push - pushes the tags and branch
- fedpkg build
And when somebody attempts to do a untagged build, it would fail,
similarly to what it does now when you try to build unpushed changes.
Example template:
# You are about to tag foobar 1.1-1
# Here are the commit messages since 1.0-6
#
# This is the 1st commit message:
Update to 1.1
# This is the commit message #2:
Damn sources
# This is the commit message #3:
Fix the tests
# This is the commit message #4:
Typo
# Please amend the commit messages to a %changelog entry. Lines
starting
# with '#' will be ignored, and an empty message aborts the release.
# If you like to change the release number, abort the process and
follow
# <link to docs>
#
# Author: Miro Hrončok <mhroncok(a)redhat.com>
# Date: Sun Jan 12 22:54:32 2020 +0100
#
# Use --author and/or --date to change the above.
While I like the annotated tag proposal, I would really appreciate if
the first step was replacing the:
~~~
%changelog
* Tue Jan 07 2020 Vít Ondruch <vondruch(a)redhat.com> - 2.7.0-1
- Upgrade to Ruby 2.7.0.
- Drop useless %%{rubygems_default_filter}.
- Fix checksec 2.0+ compatibility.
* Tue Jun 25 2019 Vít Ondruch <vondruch(a)redhat.com> - 2.6.3-121
- Properly support %%prerelease in %%gemspec_ macros.
... snip ...
~~~
in .spec file by
~~~
%changelog
%include changelog
~~~
where the `changelog` file would be either available with the original
changelog content in repository or if it was not available, it would be
provided by build infra. The *provided by infra* is the most important
thing here. This IMO would allow us incrementally improve the situation.
Then we could discuss how to provide the content of the `changelog`
file, while maintainers could still maintain old changelogs, or they
could split the changelog into separate `changelog` file and maintain it
there, or leave it for infrastructure (simple collecting git commits) or
using annotated tags.
Vít