[DISCUSS] RFC: Shipping Geode patch releases

[Anthony Baker <ab...@apache.org>]

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

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum <jb...@pivotal.io>]

NOTE: Sorry Udo, you caught me mid-flight in my response to Alexander...

Alexander-

Certainly there are circumstances (e.g. Security vulnerabilites) which may
warrant a patch/maintenance release sooner than 6 weeks, along with other
circumstances may cause a release to take longer than 6 weeks, if
"important" changes, as called out in #2, take a bit longer to complete
than expected.

Sometimes this might be dictated by upstream dependencies as well (e.g.
Apache Lucene).  You should take the 6 week window to mean a general
guideline, and not an absolute, in order to have predictability so users
can plan upgrades, even for patch releases, which is the best interest of
everyone to stay current with.

I would find it unlikely that there would not be a need for regular patches
~every 6 weeks to N, N-1 and N-2 versions.  This is not to say is "always"
going to be "important" changes, but I suspect most of the time, certain
things probably can and should be backported, regardless of "our workload
effort" that I am quite certain our users are not as concerned about.

-j

On Tue, Feb 25, 2020 at 1:42 PM Udo Kohlmeyer <ud...@apache.com> wrote:

>  From the proposal it seems we are departing from the initial delivery
> paradigm of "always upgrade to the latest version, because all fixes are
> going in there", to the more product orientated approach of, there is a
> support lifespan for each {major}-{minor} version. Which is a more
> traditional product approach.
>
> Is there a specific reason we advocating for moving away from "the fix
> will be in the latest release X:Y:Z" ?
>
> The current methodology or the community voting on changes being
> cherry-picked is related to fixes making it into an unreleased version
> of Geode. From the proposal, are we advocating for extra voting "Do we
> include fix GEODE-XXXX, into N , N-1 or N-2? " This does seem to be
> something that might be more work for the community, rather than just
> updating to latest RELEASE. Or is the suggestion that closer to each
> release period, a list of candidate tickets are proposed for back
> porting? Or is the back porting and vote on inclusion done based on
> discretion and on a ticket by ticket basis?
>
> With the reduced scope of supported versions, does this also mean we
> reduce scope of backward compatibility testing between versions? i.e can
> we now change our backward compatibility testing to mimic the same
> behavior where we only test compatibility between, HEAD,N,N-1 and N-2?
>
> --Udo
>
> On 2/25/20 11:51 AM, Alexander Murmann wrote:
> > 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 <amurmann@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 <on...@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 <ab...@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 <on...@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 <
> >> amurmann@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 <on...@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 <ab...@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
> >>
> >
>


-- 
-John
Spring Data Team

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Dick Cavender <dc...@pivotal.io>]

+1 to the proposal and the plan outlined above for the transition period.


On Mon, Mar 2, 2020 at 4:33 PM Owen Nichols <on...@pivotal.io> wrote:

> My interpretation is that we would cut support/1.13 from develop on the
> next scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x
> patch releases directly from this branch.  Otherwise it becomes a two-step
> process if all patches have to be cherry-picked from develop -> support/x.y
> -> release/x.y.z.  Assuming patch-worthy fixes will already be vetted by
> the community as critical in order to bring them to support/x.y, it doesn’t
> seem like we’d gain anything but unnecessary complexity to require a second
> round of sifting.
>
> support/1.12 will have to be cut from release/1.12.0 as a one-time special
> case, but the end result should be indistinguishable.
>
> > On Mar 2, 2020, at 4:24 PM, Dan Smith <ds...@pivotal.io> wrote:
> >
> > +1 to the proposal as written.
> >
> > The proposal does talk about support branches, but doesn't describe when
> > they are created. Is the idea that we create a support/1.X branch as soon
> > as we release geode 1.X, and then create release branches off of that as
> > needed?
> >
> > -Dan
>
>

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Dan Smith <ds...@pivotal.io>]

>
> My interpretation is that we would cut support/1.13 from develop on the
> next scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x
> patch releases directly from this branch.  Otherwise it becomes a two-step
> process if all patches have to be cherry-picked from develop -> support/x.y
> -> release/x.y.z.  Assuming patch-worthy fixes will already be vetted by
> the community as critical in order to bring them to support/x.y, it doesn’t
> seem like we’d gain anything but unnecessary complexity to require a second
> round of sifting.
>

Sounds reasonable to me.

-Dan

On Mon, Mar 2, 2020 at 4:33 PM Owen Nichols <on...@pivotal.io> wrote:

> My interpretation is that we would cut support/1.13 from develop on the
> next scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x
> patch releases directly from this branch.  Otherwise it becomes a two-step
> process if all patches have to be cherry-picked from develop -> support/x.y
> -> release/x.y.z.  Assuming patch-worthy fixes will already be vetted by
> the community as critical in order to bring them to support/x.y, it doesn’t
> seem like we’d gain anything but unnecessary complexity to require a second
> round of sifting.
>
> support/1.12 will have to be cut from release/1.12.0 as a one-time special
> case, but the end result should be indistinguishable.
>
> > On Mar 2, 2020, at 4:24 PM, Dan Smith <ds...@pivotal.io> wrote:
> >
> > +1 to the proposal as written.
> >
> > The proposal does talk about support branches, but doesn't describe when
> > they are created. Is the idea that we create a support/1.X branch as soon
> > as we release geode 1.X, and then create release branches off of that as
> > needed?
> >
> > -Dan
>
>

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Owen Nichols <on...@pivotal.io>]

My interpretation is that we would cut support/1.13 from develop on the next scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x patch releases directly from this branch.  Otherwise it becomes a two-step process if all patches have to be cherry-picked from develop -> support/x.y -> release/x.y.z.  Assuming patch-worthy fixes will already be vetted by the community as critical in order to bring them to support/x.y, it doesn’t seem like we’d gain anything but unnecessary complexity to require a second round of sifting.

support/1.12 will have to be cut from release/1.12.0 as a one-time special case, but the end result should be indistinguishable.

> On Mar 2, 2020, at 4:24 PM, Dan Smith <ds...@pivotal.io> wrote:
> 
> +1 to the proposal as written.
> 
> The proposal does talk about support branches, but doesn't describe when
> they are created. Is the idea that we create a support/1.X branch as soon
> as we release geode 1.X, and then create release branches off of that as
> needed?
> 
> -Dan

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Dan Smith <ds...@pivotal.io>]

+1 to the proposal as written.

The proposal does talk about support branches, but doesn't describe when
they are created. Is the idea that we create a support/1.X branch as soon
as we release geode 1.X, and then create release branches off of that as
needed?

-Dan

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum <jb...@pivotal.io>]

By sticking to the "on-demand" patch release process, then there is no
difference to the current release process, and this proposal adds nothing
of value.

On Tue, Mar 3, 2020 at 12:44 AM Aaron Lindsey <aa...@apache.org>
wrote:

> +1 to the proposal as it’s written.
>
> I’m not sure about setting regular intervals for patch releases vs
> sticking with our current “on-demand” process. I don’t think this has to be
> spelled out in this proposal. I’d be fine with sticking to “on-demand”
> patch releases as we’ve been doing for now and seeing how that goes. If
> needed we could follow that up with a proposal for regular patch release
> intervals.
>
> - Aaron
>
> > On Feb 26, 2020, at 8:45 AM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> >
> >
> >> On Feb 25, 2020, at 1:42 PM, Udo Kohlmeyer <ud...@apache.com> wrote:
> >>
> >> From the proposal it seems we are departing from the initial delivery
> paradigm of "always upgrade to the latest version, because all fixes are
> going in there", to the more product orientated approach of, there is a
> support lifespan for each {major}-{minor} version. Which is a more
> traditional product approach.
> >>
> >> Is there a specific reason we advocating for moving away from "the fix
> will be in the latest release X:Y:Z" ?
> >>
> >
> > From the proposal:
> >
> > "The Geode project has been following a model of shipping releases
> quarterly [1][2].  Using the SemVer [3] approach, these quarterly releases
> are labeled as minor versions.  Occasionally, the project has shipped patch
> releases [4] to address security vulnerabilities or really critical bugs.
> However, on the whole the project has asked users to wait until the next
> quarterly minor release to receive improvements and fixes.
> >
> > It would benefit our user community if we supported our releases for a
> period of time by back porting important fixes and providing patch
> releases.”
> >
> > I believe that taking this approach will clarify expectations and make
> it easier for users to rely on Geode for their projects.
> >
> >
> >> The current methodology or the community voting on changes being
> cherry-picked is related to fixes making it into an unreleased version of
> Geode. From the proposal, are we advocating for extra voting "Do we include
> fix GEODE-XXXX, into N , N-1 or N-2? " This does seem to be something that
> might be more work for the community, rather than just updating to latest
> RELEASE. Or is the suggestion that closer to each release period, a list of
> candidate tickets are proposed for back porting? Or is the back porting and
> vote on inclusion done based on discretion and on a ticket by ticket basis?
> >
> > I think the process will follow our approach to back porting fixes onto
> a release branch:
> >
> > 1) When you fix an “important” issue, note that it will need to be back
> ported onto the correct set of support branches.
> > 2) The assigned release manager for the support branch will coordinate
> community consensus and help with cherry-picking the change as well as
> ensuring the pipelines are staying green.
> >
> >>
> >> With the reduced scope of supported versions, does this also mean we
> reduce scope of backward compatibility testing between versions? i.e can we
> now change our backward compatibility testing to mimic the same behavior
> where we only test compatibility between, HEAD,N,N-1 and N-2?
> >>
> >
> > Great question.  I think we continue to follow our SerVer approach to
> naming versions, as well as following the backwards compatibility
> guidelines described in [1[.  In short, I don’t think this N-2 changes our
> requirements—this idea is more about what versions we will patch.
> >
> >
> > Anthony
> >
> > [1]
> https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility
> >
> >
> >
> >
> >> --Udo
> >>
> >> On 2/25/20 11:51 AM, Alexander Murmann wrote:
> >>> 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 <
> amurmann@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 <on...@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 <ab...@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 <on...@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 <
> >>>> amurmann@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 <
> onichols@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 <ab...@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
> >>>>
> >>>
> >
>
>

-- 
-John
Spring Data Team

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Aaron Lindsey <aa...@apache.org>]

+1 to the proposal as it’s written.

I’m not sure about setting regular intervals for patch releases vs sticking with our current “on-demand” process. I don’t think this has to be spelled out in this proposal. I’d be fine with sticking to “on-demand” patch releases as we’ve been doing for now and seeing how that goes. If needed we could follow that up with a proposal for regular patch release intervals.

- Aaron

> On Feb 26, 2020, at 8:45 AM, Anthony Baker <ab...@pivotal.io> wrote:
> 
> 
> 
>> On Feb 25, 2020, at 1:42 PM, Udo Kohlmeyer <ud...@apache.com> wrote:
>> 
>> From the proposal it seems we are departing from the initial delivery paradigm of "always upgrade to the latest version, because all fixes are going in there", to the more product orientated approach of, there is a support lifespan for each {major}-{minor} version. Which is a more traditional product approach.
>> 
>> Is there a specific reason we advocating for moving away from "the fix will be in the latest release X:Y:Z" ?
>> 
> 
> From the proposal:
> 
> "The Geode project has been following a model of shipping releases quarterly [1][2].  Using the SemVer [3] approach, these quarterly releases are labeled as minor versions.  Occasionally, the project has shipped patch releases [4] to address security vulnerabilities or really critical bugs.  However, on the whole the project has asked users to wait until the next quarterly minor release to receive improvements and fixes.
> 
> It would benefit our user community if we supported our releases for a period of time by back porting important fixes and providing patch releases.”
> 
> I believe that taking this approach will clarify expectations and make it easier for users to rely on Geode for their projects.
> 
> 
>> The current methodology or the community voting on changes being cherry-picked is related to fixes making it into an unreleased version of Geode. From the proposal, are we advocating for extra voting "Do we include fix GEODE-XXXX, into N , N-1 or N-2? " This does seem to be something that might be more work for the community, rather than just updating to latest RELEASE. Or is the suggestion that closer to each release period, a list of candidate tickets are proposed for back porting? Or is the back porting and vote on inclusion done based on discretion and on a ticket by ticket basis?
> 
> I think the process will follow our approach to back porting fixes onto a release branch:
> 
> 1) When you fix an “important” issue, note that it will need to be back ported onto the correct set of support branches.
> 2) The assigned release manager for the support branch will coordinate community consensus and help with cherry-picking the change as well as ensuring the pipelines are staying green.
> 
>> 
>> With the reduced scope of supported versions, does this also mean we reduce scope of backward compatibility testing between versions? i.e can we now change our backward compatibility testing to mimic the same behavior where we only test compatibility between, HEAD,N,N-1 and N-2?
>> 
> 
> Great question.  I think we continue to follow our SerVer approach to naming versions, as well as following the backwards compatibility guidelines described in [1[.  In short, I don’t think this N-2 changes our requirements—this idea is more about what versions we will patch.
> 
> 
> Anthony
> 
> [1] https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility
> 
> 
> 
> 
>> --Udo
>> 
>> On 2/25/20 11:51 AM, Alexander Murmann wrote:
>>> 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 <am...@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 <on...@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 <ab...@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 <on...@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 <
>>>> amurmann@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 <on...@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 <ab...@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
>>>> 
>>> 
> 

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Anthony Baker <ab...@pivotal.io>]

> On Feb 25, 2020, at 1:42 PM, Udo Kohlmeyer <ud...@apache.com> wrote:
> 
> From the proposal it seems we are departing from the initial delivery paradigm of "always upgrade to the latest version, because all fixes are going in there", to the more product orientated approach of, there is a support lifespan for each {major}-{minor} version. Which is a more traditional product approach.
> 
> Is there a specific reason we advocating for moving away from "the fix will be in the latest release X:Y:Z" ?
> 

From the proposal:

"The Geode project has been following a model of shipping releases quarterly [1][2].  Using the SemVer [3] approach, these quarterly releases are labeled as minor versions.  Occasionally, the project has shipped patch releases [4] to address security vulnerabilities or really critical bugs.  However, on the whole the project has asked users to wait until the next quarterly minor release to receive improvements and fixes.

It would benefit our user community if we supported our releases for a period of time by back porting important fixes and providing patch releases.”

I believe that taking this approach will clarify expectations and make it easier for users to rely on Geode for their projects.


> The current methodology or the community voting on changes being cherry-picked is related to fixes making it into an unreleased version of Geode. From the proposal, are we advocating for extra voting "Do we include fix GEODE-XXXX, into N , N-1 or N-2? " This does seem to be something that might be more work for the community, rather than just updating to latest RELEASE. Or is the suggestion that closer to each release period, a list of candidate tickets are proposed for back porting? Or is the back porting and vote on inclusion done based on discretion and on a ticket by ticket basis?

I think the process will follow our approach to back porting fixes onto a release branch:

1) When you fix an “important” issue, note that it will need to be back ported onto the correct set of support branches.
2) The assigned release manager for the support branch will coordinate community consensus and help with cherry-picking the change as well as ensuring the pipelines are staying green.

> 
> With the reduced scope of supported versions, does this also mean we reduce scope of backward compatibility testing between versions? i.e can we now change our backward compatibility testing to mimic the same behavior where we only test compatibility between, HEAD,N,N-1 and N-2?
> 

Great question.  I think we continue to follow our SerVer approach to naming versions, as well as following the backwards compatibility guidelines described in [1[.  In short, I don’t think this N-2 changes our requirements—this idea is more about what versions we will patch.


Anthony

[1] https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility




> --Udo
> 
> On 2/25/20 11:51 AM, Alexander Murmann wrote:
>> 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 <am...@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 <on...@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 <ab...@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 <on...@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 <
>>> amurmann@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 <on...@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 <ab...@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
>>> 
>> 

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Udo Kohlmeyer <ud...@apache.com>]

 From the proposal it seems we are departing from the initial delivery 
paradigm of "always upgrade to the latest version, because all fixes are 
going in there", to the more product orientated approach of, there is a 
support lifespan for each {major}-{minor} version. Which is a more 
traditional product approach.

Is there a specific reason we advocating for moving away from "the fix 
will be in the latest release X:Y:Z" ?

The current methodology or the community voting on changes being 
cherry-picked is related to fixes making it into an unreleased version 
of Geode. From the proposal, are we advocating for extra voting "Do we 
include fix GEODE-XXXX, into N , N-1 or N-2? " This does seem to be 
something that might be more work for the community, rather than just 
updating to latest RELEASE. Or is the suggestion that closer to each 
release period, a list of candidate tickets are proposed for back 
porting? Or is the back porting and vote on inclusion done based on 
discretion and on a ticket by ticket basis?

With the reduced scope of supported versions, does this also mean we 
reduce scope of backward compatibility testing between versions? i.e can 
we now change our backward compatibility testing to mimic the same 
behavior where we only test compatibility between, HEAD,N,N-1 and N-2?

--Udo

On 2/25/20 11:51 AM, Alexander Murmann wrote:
> 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 <am...@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 <on...@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 <ab...@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 <on...@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 <
>> amurmann@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 <on...@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 <ab...@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
>>
>

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Alexander Murmann <aj...@gmail.com>]

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 <am...@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 <on...@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 <ab...@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 <on...@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 <
> amurmann@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 <on...@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 <ab...@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

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum <jb...@pivotal.io>]

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 <am...@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 <on...@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 <ab...@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 <on...@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 <amurmann@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 <on...@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 <ab...@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

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Alexander Murmann <am...@apache.org>]

>
> 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 <on...@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 <ab...@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 <on...@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 <am...@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 <on...@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 <ab...@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
> >>>>
> >>>>
> >>
> >

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Owen Nichols <on...@pivotal.io>]

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 <ab...@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 <on...@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 <am...@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 <on...@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 <ab...@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
>>>> 
>>>> 
>> 
> 

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Dave Barnes <db...@pivotal.io>]

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 <ab...@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 <on...@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 <am...@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 <on...@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 <ab...@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
> >>>
> >>>
> >
>
>

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Anthony Baker <ab...@pivotal.io>]

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 <on...@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 <am...@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 <on...@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 <ab...@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
>>> 
>>> 
> 

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Owen Nichols <on...@pivotal.io>]

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?)

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”?


> On Feb 24, 2020, at 11:00 AM, Alexander Murmann <am...@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 <on...@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 <ab...@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
>> 
>> 

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Alexander Murmann <am...@pivotal.io>]

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 <on...@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 <ab...@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
>
>

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Alexander Murmann <am...@pivotal.io>]

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 <on...@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 <ab...@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
>
>

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Owen Nichols <on...@pivotal.io>]

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 <ab...@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

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Owen Nichols <on...@pivotal.io>]

With the release of Geode 1.12.0 (awesome!), we have a new branch naming convention starting today:

release/1.12.0 is now support/1.12

As per this RFC, support/1.12 and an accompanying pipeline[1] will be maintained until Dec 31 2020.

Critical fixes may be proposed at any time.  The fix should already be on develop.  If it is not a clean&simple cherry-pick, please prepare a PR against desired support branch(es).

The usual three “+1” votes are needed to bring a proposed fix.

Anyone in the Geode community may at any time propose making a patch release from a support branch.

-Owen

[1] https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main

> On Mar 13, 2020, at 4:10 PM, Anthony Baker <ab...@apache.org> wrote:
> 
> Based on the consensus in this thread, we will move forward with this
> proposal.  We can work out the exact mechanics after we release
> v1.12.0 and move that into a support mode.
> 
> Thanks for all the feedback.
> 
> Anthony
> 
> 
> On Fri, Feb 21, 2020 at 5:30 PM Anthony Baker <ab...@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

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Anthony Baker <ab...@apache.org>]

Based on the consensus in this thread, we will move forward with this
proposal.  We can work out the exact mechanics after we release
v1.12.0 and move that into a support mode.

Thanks for all the feedback.

Anthony


On Fri, Feb 21, 2020 at 5:30 PM Anthony Baker <ab...@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

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Owen Nichols <on...@pivotal.io>]

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 <ab...@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

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Anthony Baker <ab...@apache.org>]

Based on the consensus in this thread, we will move forward with this
proposal.  We can work out the exact mechanics after we release
v1.12.0 and move that into a support mode.

Thanks for all the feedback.

Anthony


On Fri, Feb 21, 2020 at 5:30 PM Anthony Baker <ab...@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