Hi John, I think what you are calling out in 1. and 2. matches what was discussed in the proposal and thread. Please call out if you disagree on a detail.
What's your reasoning behind 3? I see little reason to ship a patch release (which is significant work) if there was no important fix. Likewise I am concerned about waiting to ship a critical fix to our users or leave them with gaping security vulnerabilities when we have a fix, but the next patch release train doesn't depart for several weeks. On Tue, Feb 25, 2020 at 11:41 AM John Blum <jb...@pivotal.io> wrote: > Real quick thought... IMO: > > 1. There should be patch (maintenance) releases for each major.minor, up to > N-2 for a set period of time (e.g. 1.5 years), or until N-2 becomes N-3 > where N-3 is no longer supported. > 2. All important changes should be backported. I say "important" loosely > since that should be decided by the community, but in general, that means > Blocker, Critical, Security fixes or other changes that can impact the > contract, functionality or proper behavior of Apache Geode in whatever > context. > 3. Patch (maintenance) releases should occur at a regular, "predictable" > intervals (e.g. every 6 weeks), not on an adhoc basis. > > $0.02 > -John > > > On Tue, Feb 25, 2020 at 11:23 AM Alexander Murmann <amurm...@apache.org> > wrote: > > > > > > > Or, we could emphasize the shift in process with bigger changes: > > > i. Instead of cutting "release/1.13.0" on May 4, we could instead cut > > > "support/1.13" > > > ii instead of creating "apache-release-1-13-0-main" pipeline, we would > > > instead create "apache-release-1-13-main" > > > iii. Instead of cleaning up the pipeline and branch after 1.13.0 was > > > released, we could keep it around for 9 months and re-use it for > > collecting > > > patches and making patch releases during that time. > > > > > +1 I cannot see any argument against cutting a release branch for the > minor > > version and keeping it around. > > > > The community process around deciding how long to gather fixes before > > > shipping a patch release isn’t any easier either way. > > > > How about we wait for someone to call out the need to ship a patch > > release. At > > that point we use the rule of thumb "aim for no more than 1 patch release > > per minor per month" to guide our community discussion. > > > > I would like to see more discussion on the community impact of increasing > > > the commitment required of a release manager. In the short term it > would > > > be good for Geode to have someone focused on improving the release > > process > > > for a longer period of time than a single release. But in the long > term, > > > people may be less likely to volunteer, and release experience will be > > > concentrated in fewer members of the community... > > > > Are there more things that could be automated? When I filled the role ~1 > > year ago there was lots of copying and pasting of scripts and I even > wrote > > one to help validate fixVersions. Although release process automation > > should probably be taken to a different discussion, since it's mostly > > separate form Anthony's proposal. > > > > > > On Tue, Feb 25, 2020 at 11:06 AM Owen Nichols <onich...@pivotal.io> > wrote: > > > > > These concerns make sense. We could satisfy them within our existing > > > “on-demand” process: > > > > > > 1) the first time there is a change to backport to support branches, > > > propose the patch release. Now we have a branch. Decide as a > community > > > how urgently it needs to be released vs how long to hold it open for > > other > > > potential fixes. > > > > > > Or, we could emphasize the shift in process with bigger changes: > > > i. Instead of cutting "release/1.13.0" on May 4, we could instead cut > > > "support/1.13" > > > ii instead of creating "apache-release-1-13-0-main" pipeline, we would > > > instead create "apache-release-1-13-main" > > > iii. Instead of cleaning up the pipeline and branch after 1.13.0 was > > > released, we could keep it around for 9 months and re-use it for > > collecting > > > patches and making patch releases during that time. > > > > > > The community process around deciding how long to gather fixes before > > > shipping a patch release isn’t any easier either way. > > > > > > One advantage of our current process is that a release doesn’t happen > > > until someone volunteers to make it happen. We can do as many or as > few > > > patch releases as the community is willing -- a release always has a > > > champion. > > > > > > I would like to see more discussion on the community impact of > increasing > > > the commitment required of a release manager. In the short term it > would > > > be good for Geode to have someone focused on improving the release > > process > > > for a longer period of time than a single release. But in the long > term, > > > people may be less likely to volunteer, and release experience will be > > > concentrated in fewer members of the community... > > > > > > > > > > On 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 > > > >>>> > > > >>>> > > > >> > > > > > > > > > -- > -John > Spring Data Team > -- Alexander J. Murmann (650) 283-1933
