Hi, On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote: > For the changelog, we believe we have a potential good solution: > - The changelog will be automatically generated using an external `changelog` > file as well as the commit history ... > If you wanted to edit the changelog, you would: > - Generate the changelog locally via a command like: > `fedpkg generate-changelog > changelog` > - Edit `changelog` as desired > - Commit and push the changes This means that a separate commit needs to be done *after* on top of the commits doing the actual changes. It's a bit disappointing, but on its own would not be too bad, since we can have fedpkg provide a higher level command that combines generate-changelog and build... One important feature will work: being able to cherry-pick commit between branches w/o spurious conflicts. As long as the "real" change to the spec file are done in separate commits, and the changelog commit is another commit on top, then when cherry-picking to another branch, the "real" commits would be cherry-pickable, and then the changelog commit would be recreated using the automation, OK. But it doesn't work quite as nicely with something similar: merging branches. A simple 'git merge' would result in conflicts. Also, if an amendment to the changelog is done, and the same change needs to be done in the changelog in a different branch, trying to cherry-pick the fix commit would most likely result in a merge conflict. Considering these three drawbacks (separate commit step and resulting log noise, merge conflicts), I'd very much hope for a solution where the changelog is never stored in the version control, and is always autogenerated at srpm creation time. We should never try to chery-pick commits that have changelog entries with actual date or e-v-r texts, since this will inevitably lead to merge conflicts. A different approach: - we have 'fedpkg generate-changelog' (which does all the git log extraction that was described, I think that part is OK), - the output from this command included in the srpm at srpm generation time and never committed to version control, - the output is annotated with the source commits hashes, so we can see where each line came from. At any time, the packager can run 'fedpkg generate-changelog' to see how the output looks like. If they see something they don't like, if the commits haven't been pushed out yet, they can immediately run 'git commit --amend' and recheck. If they have been pushed out, an override to the changelog could be committed as part of a commit message text. Git-changelog-suppress: ad5555b42e or Git-changelog-suppress: ad5555b42e..efefedeadb or Git-changelog-replace: ad5555b42e Some other text with typos fixed that completely overrides whatever was generated from ad5555b42e. or Git-changelog-append: ad5555b42e (additional clarification for commit ad5555b42e, e.g. bug #12345) This would have the following advantages: - git log is the sole source of truth - there are no cherry-pick or merge conflicts - there is no separate "now I'm done and I need to do another commit before building" thing. The assumption is that those Git-changelog-* macros would only be used occasionally, if the bad changelog entry was not noticed before pushing the changes out. (One nitpick: when cherry-picking between branches, hashes of the cherry-picked commits change, so "ad5555b42e" in the example above would stop working. This is handled by using 'git cherry-pick -x'. 'fedpkg generate-changelog' would look at any hash in a "(cherry picked from commit ...)" line.) As how to hook this up with rpm, looking at https://pagure.io/packaging-committee/pull-request/942#comment-108542, a macro like %generate_changelog could be provided that would simply shell out to 'fedpkg generate-changelog'. I'll comment separate on the -release part. Zbyszek _______________________________________________ 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
