Thanks for proposing this, Anthony!
> I don’t think it’s necessary for this proposal to re-define or clarify > what constitutes a critical fix; it sounds like the bar would be the same > as the standard we already apply when back-porting to release branches > (proposal /w justification, and 3 votes in favor). The only difference > seems to be that now proposals may list up to three target branches, not > just one. > re: Owen TL;DR: +1 using the same process as we use for merging critical fixes during an ongoing release seems appropriate. Generally merging a fix to a dormant release branch seems less problematic than merging a fix to an active release branch where a merge will reset all release work that has already happened. The cost of merging to a dormant release branch is much lower than merging to one that's being actively released. Ideally we could just do a PR to merge fixes back in most cases. Unfortunately, I believe it's unreasonable to expect that everyone will be aware at all times what's actively being released and what's not => Let's pretend we are always shipping these branches. On Fri, Feb 21, 2020 at 7:35 PM Owen Nichols <onich...@pivotal.io> wrote: > Thank you Anthony for proposing this “N-2” support policy. It isn’t a big > change, but it is helpful to know that the Geode PMC will now be standing > behind (and ready to vote on) patch releases within a 9-month window. > > Overall, this sounds much like how 1.9.1 and 1.9.2 started as community > proposals, found a release manager, and went on to be successfully released. > > I don’t think it’s necessary for this proposal to re-define or clarify > what constitutes a critical fix; it sounds like the bar would be the same > as the standard we already apply when back-porting to release branches > (proposal /w justification, and 3 votes in favor). The only difference > seems to be that now proposals may list up to three target branches, not > just one. > > I also don’t think it’s necessary to alter our current process to maintain > a standing "support/x.y" branch. The proposal states that patch releases > will be “ad-hoc (as needed)”. Our current process serves this quite well: > we propose a patch release at the time it is needed, then get a release > manager and create a release branch specifically for that release (e.g. > release/1.9.2 was created from the rel/v1.9.1 tag), then clean up > afterwards so no unattended pipelines or branches linger. > > The rotating release manager role has been a hallmark of the Geode > community process, so I hope this proposal will not dissuade anyone > interested in helping with a release. However, getting the automation > improvements we need will require some continuity over several releases. I > would love to volunteer for this! > > -Owen > > > On Feb 21, 2020, at 5:30 PM, Anthony Baker <aba...@apache.org> wrote: > > > > Hi everyone, > > > > I'd like to propose shipping patch releases of Geode as a way to > > improve our engagement and support of our user community. Please > > review the details in the linked RFC [1] and kindly offer your > > thoughts in this thread. > > > > > > Thanks, > > Anthony > > > > [1] > https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases > >
