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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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