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'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