I put up https://github.com/apache/beam/pull/32318 to add this to our docs since it seems like there is silent consensus (and this is easily reversible if there's not).
> I've been burned several times recently through implicit assumptions, so i felt it was worth mentioning. :) Agreed - thanks! Thanks, Danny On Mon, Aug 26, 2024 at 5:11 PM Robert Burke <rob...@frantil.com> wrote: > I've been burned several times recently through implicit assumptions, so i > felt it was worth mentioning. :) > > On Mon, Aug 26, 2024, 9:09 AM Danny McCormick via dev <dev@beam.apache.org> > wrote: > >> > 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. >> >> I agree, just haven't done it yet (PRs welcome) since it doesn't make >> sense to automate a process unless we want to keep it :). That piece was >> fully ripped from the current docs. >> >> > Is the gap between current automation and path releases just that we >> can't choose the base branch to start from? >> >> Yes; it is probably a 1-2 line change. >> >> Thanks, >> Danny >> >> On Mon, Aug 26, 2024 at 4:20 PM Kenneth Knowles <k...@apache.org> wrote: >> >>> Is the gap between current automation and path releases just that we >>> can't choose the base branch to start from? >>> >>> On Fri, Aug 23, 2024 at 10:40 PM Robert Burke <rob...@frantil.com> >>> wrote: >>> >>>> 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 >>>>>> >>>>>>
