Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):
> 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.
Actually, I took the liberty and filled this guideline proposal change
[1], which just suggests keeping changelogs in `changelog` file, outside
of the .spec file.
Vít
[1] https://pagure.io/packaging-committee/pull-request/942
_______________________________________________
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
