On 16/08/2026 18:05, Rémy Maucherat wrote:
On Sun, Aug 16, 2026 at 4:39 PM Mark Thomas <[email protected]> wrote:All, I've been thinking about further increasing the automation we use the build releases. There are various drivers for this including: - potentially more frequent releases (in response to the volume of AI security issues) - easier for any committer to roll a release (no need to set up eSigner access) - reduced cost (each additional eSigner user costs the ASF $39/month) I believe all the components we would need to build releases via a GitHub action are in place. With reproducible builds, we can fully validate that the binaries built by automation are not subverted. If there is general agreement to head in this direction, my thinking was that we could work out a high-level plan between now and CoC Glasgow and then work on this in the hackathon. Thoughts?I'm not sure, I thought the ASF wanted us to use their new tool instead.
Good point. Using a GitHub action was just an implementation detail. We could (should) look at what Apache Trusted Releases provides / will provide.
Also this would make us 100% dependent on GH ...
That is certainly a concern. I wouldn't want us to be in that position. I've seen too many instances of either GitHub actions being down or (more often) one ASF project hogging all the runners for an extended period of time. It should be possible to construct this in such a way that it can run on a CI system or locally. That does mean we'd need access to valid ssl.com credentials (I'm confident that is a problem that can be solved) or - in extremis - we release with the Windows installer unsigned.
What able the general idea of getting the releases to a point where we have the option to use automation to produce the releases and, in normal circumstances, use it?
Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
