Dne 21. 01. 20 v 9:36 Pavel Raiskup napsal(a):
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...
I assume that there will be some tags which allow to exclude some
specific messages from changelog. E.g. yesterday, I did two rebuilds of
libguestfs:
https://src.fedoraproject.org/rpms/libguestfs/c/d33d482cf7b0cf4e1fa48d229...
https://koji.fedoraproject.org/koji/taskinfo?taskID=40786204
and
https://src.fedoraproject.org/rpms/libguestfs/c/cbdfa80fe9eb4a26a08075841...
https://koji.fedoraproject.org/koji/taskinfo?taskID=40786518
The first failed due to some Koji issues. Therefore I had to bump the
release and do another one. If this situation happened when the
changelog is generated from git log, I would expect that adding some
keyword such as "[skip changelog]" (there are quite commonly used
similar hints for CI nowadays [1]) would instruct the generator to leave
the second commit out of the changelog, because it does not provide any
additional value to user.
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.
Don't forget that single Bodhi update might ship several builds.
Vít
[1]
https://docs.travis-ci.com/user/customizing-the-build/#skipping-a-build
> 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