Matthew Miller wrote:
> 1. Put real changelog info in the git log and have a separate standard
> (uh, or better name, but I bet that
>    one doesn't have any conflicts!) which lives in dist-git (but not in
>    the package) and gets fed into bodhi and whatever other tooling

The changelog in the spec file could serve that purpose if we could get
rid of all the "rebuilt" entries. I would rather write the release notes
in the spec file than in a separate file. If the requirement for a new
changelog entry for every build could be dropped, then the RPM changelog
could become the release notes (although, if it would be called
"%release_notes" instead of "%changelog", then it might help packagers
understad what to write there).

A separate file doesn't in itself prevent merge conflicts, but dropping
the "rebuilt" entries would make merge conflicts rarer.

Of course, if upstream provides a file with suitable release notes,
then the spec should just refer to that, so that the packager doesn't
have to copy and paste them.

Regarding the issue that started this thread: Users aren't expected to
know about RPM macros, so presence of an RPM macro in the release notes
would indicate that the packager has misunderstood what release notes
should contain.

Björn Persson
devel mailing list --
To unsubscribe send an email to

Reply via email to