On 13. 01. 20 12:28, Pierre-Yves Chibon wrote:
On Sun, Jan 12, 2020 at 10:56:00PM +0100, Miro Hrončok wrote:
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?
It was the sentence just above the section you quoted here ;-)
"For the latter, we discussed the idea of using annotated git tags this fall."
Sorry about that, I must have missed it.
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.
This is definitely an option, it might even be the simplest to implement.
One observation about it though is that we would still have three changelogs
then, git commit, git tags and bodhi update.
So it is easier to implement as we rely on the packager to do the review of what
goes into the RPM changelog.
We still have Neal's question: do we let packager edit these tags? (Considering
we allow editing old changelog entries, I guess we could).
If we build from the tag hash in Koji, we cannot.
If we build from the commit hash and let Koji "fetch" the changelog from
existing tags, we can.
We still need to construct the changelog entries from old tags, to the second
option makes sense.
One question, if the release is set in koji and the changelog in git tag.
If I tag foo 1.0 with a first changelog entry, then koji builds 1.0-1 with that
changelog.
I find out that there is a mistake in the changelog, so I edit the tag, won't
koji build 1.0-2? Which would then have two repeating changelog entries one for
-1 with the error and one for -2 with the fix.
Does it matter?
Currently, you cannot change already built existing changelog entry without a
bump and rebuild. This would be the same:
1. You change the changelog entry of 1.0-1.
2. You attempt build.
3. Koji tells you 1.0-1 was already build.
4. You add another entry.
It doesn't matter that much. Obviously, the ability to edit tags puts some
constrains on how the release is counted:
- if it is counted simply from number of tags, you cannot ever remove them, just
edit them to "empty changelog"
- locally, it counts all tags, and in Koji, only pushed tags, this may produce
confusion in corner cases - even if we only count pushed tags locally, somebody
else might have pushed another one in the meantime
- Hence, we might count the release number from commits, always
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
