Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a): > 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 would not need any extra commit, if you modified manually the changelog with the last entry. Which should be not problem, considering that `fedpkg generate-changelog > changelog` would be executed locally and you can amend the last commit with the changelog. Vít > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
