[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to watch pypi.org

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.


Thomas Goirand (zigo)

Reply to: