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 >>>>> >>>>>
