The proposal mentions "semi-permanent community release managers". Assuming that a patch release is simpler than a full release, these patch releases might serve well as training opportunities for first-time release managers. +1 if that's the case.
On Tue, Feb 25, 2020 at 9:29 AM Anthony Baker <aba...@pivotal.io> wrote: > Here’s a couple things I’d like to avoid: > > 1) Issuing a patch release for every single commit that we back port onto > a supported minor version. This seems like a high cost approach. Of > course, some issues may be important enough to require that. > > 2) Merging a change to develop, and then having to come back weeks later > and back porting the change to a release branch. It just seems less > optimal since I’ll have lost the context on the changes, particularly if > the cherry-pick is non-trivial. > > More comments below. > > Anthony > > > > On Feb 24, 2020, at 2:16 PM, Owen Nichols <onich...@pivotal.io> wrote: > > > > Hi Alexander, currently we don’t start a patch release until someone > proposes a critical fix, which then drives the release (the community may > propose “extra” fixes to tag along once a release branch is cut). This > keeps the process simple, neat and tidy. > > > > Another option I hadn’t thought of is to begin collecting “extra” fixes > proactively on a “dormant” branch, so that when someone finally proposes > releasing a patch, it will already be primed with a bunch of fixes. This > adds complexity (does a different standard apply to bring fixes to a > dormant branch? Are release branches separate from support branches? How > will committers be able to keep track of what is dormant and what is not?) > > > > Why not just either a) keep the release branch alive? Or b) create a > support branch from the release tag? > > > To implement an N-2 support policy, does it make more sense for Geode to > make small focused patch releases when needed, or to maintain what amounts > to “3 develop branches at all times”? > > > > To me, “develop branch” implies ongoing work. I’m proposing “support > branch” which means only important changes agreed upon by the project > community. > > > > > >> On Feb 24, 2020, at 11:00 AM, Alexander Murmann <amurm...@pivotal.io> > wrote: > >> > >> 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 > >>> > >>> > > > >
