Re: How to watch pypi.org
- To: email@example.com
- Subject: Re: How to watch pypi.org
- From: Thomas Goirand <firstname.lastname@example.org>
- Date: Sun, 1 Nov 2020 20:23:20 +0100
- Message-id: <[🔎] email@example.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <CAOh_QLeAesodC=CCL9pNO3zjBG8T2GC4rHjtOKRE0v2MLTonfA@mail.gmail.com> <CAKTje6Eq_bJssv7KFCxnRFV4wKOZLd2veUX4JRgEZAoaKZ3Wag@mail.gmail.com> <CAOh_QLfPqLvvXVCHxro9POY54TStvThJTpuNAQbfqJ0Lp=-Msw@mail.gmail.com> <email@example.com> <firstname.lastname@example.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)