On Fri, 28 Feb 2020 at 15:07, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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. I thought the main reason not to combine update in the changelog file with code commits is to avoid conflicts when cherry picking as you described. I.e. i do minor update specifically in f32 and generate changelog file in the same commit. Then I want to do normal release update for all fedora branches. I start with master (as usual) and add e.g. add a new patch and generate the changelog file because i would like to add more info, then commit. Now I cannot cherry-pick that commit into f32 without conflict. In this case we wouldn't achieve one the targets of this proposal (afaik) => getting rid of merge conflicts in changelog and release - this is cherry-picking but still it would be nice not to have conflicts there. This target isn't in the document i think but i thought this is one of the goals. clime > > 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
