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@xxxxxxxxxx>
> # 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@xxxxxxxxxx> - 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@xxxxxxxxxx> - 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
_______________________________________________
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
