Re: Ideas and proposal for removing changelog and release fields from spec file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux