better %changelog text for "Update patches"

[ktdreyer]

In Ceph we often have to rewrite our -patches branch to address build failures, etc.

If I rewrite the final patch in my -patches branch and run rdopkg patch again, rdopkg will bump the Release and insert a generic changelog entry like this:

 %changelog
+* Mon Jul 16 2018 Ken Dreyer <kdreyer@redhat.com> 2:12.2.4-34
+- Update patches
+

Currently I have to rewrite that %changelog by hand in this case.

It would be great to figure out which patches changed and print their commit message titles here, along with the rhbz numbers.

I do this with an Ubuntu-equivalent tool at https://github.com/red-hat-storage/rhcephpkg/blob/master/rhcephpkg/patch.py . It generates a package changelog like this:

  * Modified debian/patches/0150-radosgw-admin-sync-error-trim-loops-
    until-complete.patch (rhbz#1600702)

It works by reading the output of git status -s debian/patches/, and parsing that into "Deleted", "Added", "Modified" actions.

[yac]

Right, I just didn't figure out the right format/way to do this for everyone because showing every commit between releases for projects like nova would bloat the changelog into unreadability.

OTOH for rdopkg itself I do exactly that - list commits between releases and filter them by hand. Now started using reno to take care of release notes, maybe that could also be used...

Listing patches changes changes sounds like more universal option, it could even list when a ds patch was merged upstream and is now part of a release... but that would be a lots of parsing and git-ing :)

I'll try looking at the rhcephpkg/patch.py to gain some insight.

[apevec]

Another approach would be to require patches to include Reno file, see https://github.com/openstack/reno
then use that content to generate changelog entries.

[ktdreyer]

We use rdopkg with several different upstreams outside the RDO ecosystem (eg. ceph, ceph-ansible, nfs-ganesha) and it would be difficult to convince them all to use reno in order to use rdopkg effectively.

[ktdreyer]

There is one difference between Debian packaging and RPM packaging that makes this easier to provide sane changelogs within the Debian tooling.

With rdopkg's patch files, we have the commit sha1 as the first line of the file. This means that if we ever rebase the -patches branch, all the .patch files from the rebase point onward will be "changed" because the sha1s will change.

Debian's patches do not have that From $SHA1 $magic_timestamp marker, so it's easier to see when the .patch file contents change (not just the sha1 header)

[ktdreyer]

Debian's git-buildpackage tool is somewhat equivalent to rdopkg. Looks like it does not use the output of git format-patch. Instead they have a custom method that writes out each patch file in the expected way.

See the write_patch_file() method here: https://github.com/agx/git-buildpackage/blob/f9323380d8bffda9ac878be8ca50341fffc497a4/gbp/scripts/common/pq.py#L139-L249