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!
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
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
> 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
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 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
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, ti
This looks great to me.
On Fri, Aug 23, 2024 at 4:52 AM Danny McCormick via dev
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 ju