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
