Release policy and access

[jpakkane]

Currently I do all the releases. Which is fine and works, but has a bus factor of one. So maybe it should be expanded. We currently do

• Github release tarballs
• PyPI packages
• MSI packages
• (sortof) Debian packages

So who should have access rights for these? All those with admin rights in Github? Someone else?

Another question is whether some of these could be automated? Like building and uploading PyPI packages when a new release is added to GH? All of these are already done with scripts so this is more of an issue of access token management.

[eli-schwartz]

I also do Gentoo packages, although like the Debian ones this isn't strictly part of the release process for Meson itself.

I am happy to help out with releasing to github and PyPI, although I'm not set up to do MSI packages.

I already sign all git commits if possible so also signing tags and tarballs is not a problem.

[QuLogic]

PyPI publishing can be automated with Trusted Publishers; there is no need for token management, as permissions can be managed by GitHub environment settings.

[eli-schwartz]

We need to make the (PGP-signed) release for github releases either way so I'm not entirely sure how much we'd save by automatically making a second copy for PyPI.

[dcbaker]

Has anyone looked at how hard it would be to automate the signed github tarball and MSI installer? We've been doing the "trusted publishers" thing for vscode-meson, which has worked very well (although I might be a bus factor due to being the only one in the packaging orgs...)

[QuLogic]

We need to make the (PGP-signed) release for github releases either way so I'm not entirely sure how much we'd save by automatically making a second copy for PyPI.

Only the tarball is signed though? So Trusted Publishing could be triggered on releases, and do the wheel and PyPI parts.