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/d33d482cf7b0cf4e1fa48d229be9dcf08fdf6343 https://koji.fedoraproject.org/koji/taskinfo?taskID=40786204 and https://src.fedoraproject.org/rpms/libguestfs/c/cbdfa80fe9eb4a26a0807584114a02356821247c 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 > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
