Dne 28. 02. 20 v 15:06 Zbigniew Jędrzejewski-Szmek napsal(a): > 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. But the point of automation is to not edit changelog at all, isn't it? If you are going to edit it, then the automation probably did not work good enough or you have pushed something you should not have. Changelog is brittle even now. Everybody is free to edit changelog from release to release and there are no restrictions what can be done there. The situation with automation won't be worse then it is now. Vít > > 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 _______________________________________________ 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
