On Fri, Feb 28, 2020 at 12:31:23PM +0100, Vít Ondruch wrote: > > 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. Yes, but... Normally I'd do a cycle of "hack + build&test + commit". Now if I do changelog generation, I'd either have to repeat it after every step, or do it once at the end and then the last commit would suddenly contain a changelog update for multiple previous commits. Either way, this is not elegant and rather brittle. Zbyszek > > 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 > _______________________________________________ > 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 _______________________________________________ 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
