On 10/31/20 1:10 PM, Jeremy Stanley wrote: > On 2020-10-31 12:03:50 +0100 (+0100), Thomas Goirand wrote: > [...] >> On 10/31/20 3:07 AM, Jeremy Stanley wrote: >>> I have to agree, though in the upstream projects with which I'm >>> involved, those generated files are basically a lossy re-encoding of >>> metadata from the Git repositories themselves: AUTHORS file >>> generated from committer headers, ChangeLog files from commit >>> subjects, version information from tag names, and so on. Some of >>> this information may be referenced from copyright licenses, so it's >>> important in those cases for package maintainers to generate it when >>> making their source packages if not using the sdist tarballs >>> published by the project. >> >> Unfortunately, the FTP masters do not agree with you. I've been told >> that the OpenStack changelog is a way too big, and it's preferable to >> not have it in the binary packages. > > PBR started creating much smaller changelogs years ago, after you > asked ftpmaster. I get that you see no value in changelog files, but > it seems like it would be worth revisiting.
Probably it'd be worth revisiting indeed, especially by finding a way to push the logs only in the relevant -doc packages. Maybe by using the same kind of trick which I want to do with the release notes (see below), ie storing these files in the debian folder. However, if I am to put more efforts on stuff like that, my priority would be first on getting the reno release notes published in the Debian package. I've been thinking about this for a long time, and haven't figured out yet what would be the best way, with a reasonable workflow. >From the Debian perspective, I'd have to: - generate the release notes from the last version in Debian Stable, up to what's in Sid. For example, I would include all the OpenStack release notes for Stein, Train, Ussuri and Victoria in all packages uploaded for Debian Bullseye, as this would concern anyone upgrading from Buster. - make it so that release notes would be generated from Git, and maybe stored in a debian/release-notes folder, so that it wouldn't generate a diff with the original upstream tag. The drawback would be that, on each upload of a new Debian revision, the debian.tar.xz will contain the release notes, which could be of significant size (especially if they include static objects like CSS, JS, and all what makes a theme). If you have any other suggestion concerning how to handle these release notes, please let me know. Cheers, Thomas Goirand (zigo)
