On Friday, January 10, 2020 5:36:46 PM CET Pierre-Yves Chibon wrote:
Do we want to drop release and changelog from our spec file?
No. People continuously tend to forget that '%changelog' is for
end-users. Especially if some distributions already claim they can live
fine without %changelog...
Unless product managers say that 'rpm -q --changelog' is not a thing
nowadays, we should at least _allow_ being "nice" to end users. So
whatever approach we use by default -- the maintainers still have to have
a chance to maintain %changelog manually.
That said, to not loose the freedom, yes - we can implement some
automation - but only if that can be turned off. By those who care about
%changelog.
Regarding automation, I'm sceptic. See how GNU maintains ChangeLog files
... and how difficult is to edit the ChangeLog entries retrospectively
when some automation breaks it. If people claim maintaining %changelog is
too expensive so they want it generated -- having it generated is even
more expensive. I mean if maintainer cares to have '-q --changelog' nice.
With the changelog it becomes a little bit more tricky.
We currently have 3 changelogs in Fedora with 3 different target audience (this
is how I understand them):
- One for the files in the git repository, meant to be "consumed" by our
fellow packagers, not meant to leave the Fedora infrastructure
- One in the spec file describing the changes applied to it. This one is meant
to be accessible to sysadmins who want to know/check what changed in a package
- One in bodhi, meant for end-user consumption and which should give some
explanation as to why the package was updated or where information about the
update can be found
In ideal world, shouldn't the bodhi change description be equivalent to
%changelog, or at least a super-set of %changelog? If these were equivalent,
maintainers woudl have to think more about %changelog.
So we need to, somehow, merge two changelogs into one while realizing
that some
information in one may not be desirable in the other (for example the world
famous commit message: "oops I've forgot to upload the sources" does not
need to
appear in the RPM's changelog).
Would it be easier to merge the git changelog with the spec changelog or the
spec changelog with the bodhi notes?
spec changelog with bodhi notes
For the former one easy way to achieve this is to consider all the
commits since
the last successful build and have a magic keyword to either include or exclude
a commit message in the changelog.
For the latter, we discussed the idea of using annotated git tags this fall.
Both have their pros and cons, do people have some experience with either and
could share their feedback?
See the GNU (e.g. gnulib) `make ChangeLog`. The annotated tags are IMO
used in rpkg-util, and for regular git user they are "magic". People will
start
asking where the changelog is defined, how to change it, etc.
Pavel