mesonbuild
Release policy and access
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.
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.
PyPI publishing can be automated with Trusted Publishers; there is no need for token management, as permissions can be managed by GitHub environment settings.
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.
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...)
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.
As for access rights, there should probably be three for every service, just to be on the safe side. But who should those be?
I can handle GitHub and PyPI, and @dcbaker is already the second GitHub person.
No idea about the domain, I'm probably the wrong person for that anyway. :D
Debian will sort itself out in case of emergency, as Debian has policies for inactive maintainers. But it can take a while (have you seen the GNU Make 4.4 debacle? :D). I'd offer but I don't have a Debian maintainers account, so...
I can be a third for pypi, I have an account and do have a few active packages