LGTM with the addendum that if we approve of the patch process, we automate the patch PR process via an action like we do for a regular cut.
We've only been able to make our releases faster through this automation, there's no sense in dropping that when the criteria of a patch requires a quick, timely release. On Fri, Aug 23, 2024, 7:24 AM Kenneth Knowles <k...@apache.org> wrote: > This looks great to me. > > On Fri, Aug 23, 2024 at 4:52 AM Danny McCormick via dev < > dev@beam.apache.org> wrote: > >> Hey folks, we've now run 2 emergency patch releases in the last year - >> both times it has been pretty ad hoc, with someone noticing a major >> issue, suggesting a fix, and then someone with available time jumping in to >> make the release happen. There hasn't been a clear path on how much voting >> is enough/how long we should wait for the release to be voted on. While I >> think it has ended up working reasonably well, I'd like to propose a more >> formalized process for patch releases. I put together a doc to do this here >> - >> https://docs.google.com/document/d/1o4UK444hCm1t5KZ9ufEu33e_o400ONAehXUR9A34qc8/edit?usp=sharing >> >> I think the piece most folks will probably care about are the criteria >> for running a patch release and the voting process, so I've inlined both >> below. Please let me know what you think. >> >> Criteria for patch release: >> >> While Beam normally releases on a 6 week cadence, with a minor version >> bump for each release, it is sometimes necessary to make an emergency patch >> release. One of the following criteria must be met to consider a patch >> release: >> >> >> - >> >> A significant new bug was released in the last release. This could >> include major losses of functionality for a runner, an SDK bug breaking a >> feature, or a transform/IO which no longer works under certain conditions. >> Regressions which have been around for multiple releases do not meet this >> bar. >> - >> >> A major bug was discovered in a previous release which causes data >> corruption or loss >> - >> >> A critical vulnerability was discovered which exposes users to >> significant security risk. >> >> >> Voting process: >> >> Because of the time-sensitive nature of emergency patch releases, voting >> does not require a 3 day finalization period. However, it does still >> require the following: >> >> >> - >> >> 3 approving binding (PMC) votes >> - >> >> 0 disapproving (binding or non-binding) votes, or explicit >> acknowledgement from the binding voters that it is safe to ignore the >> disapproving votes. >> >> >> There are no minimum time requirements on how long the vote must be open, >> however the releaser must include their target timeline in their release >> candidate email so that voters can respond accordingly >> >> Thanks, >> Danny >> >>
