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 <aaronlind...@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 <aba...@pivotal.io> wrote:
> >
> >
> >
> >> On Feb 25, 2020, at 1:42 PM, Udo Kohlmeyer <u...@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 <
> amurm...@apache.org>
> >>>> wrote:
> >>>>
> >>>>>> Or, we could emphasize the shift in process with bigger changes:
> >>>>>> i. Instead of cutting "release/1.13.0" on May 4, we could instead
> cut
> >>>>>> "support/1.13"
> >>>>>> ii instead of creating "apache-release-1-13-0-main" pipeline, we
> would
> >>>>>> instead create "apache-release-1-13-main"
> >>>>>> iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> >>>>>> released, we could keep it around for 9 months and re-use it for
> >>>>> collecting
> >>>>>> patches and making patch releases during that time.
> >>>>>>
> >>>>> +1 I cannot see any argument against cutting a release branch for the
> >>>> minor
> >>>>> version and keeping it around.
> >>>>>
> >>>>> The community process around deciding how long to gather fixes before
> >>>>>> shipping a patch release isn’t any easier either way.
> >>>>> How about we wait for someone to call out the need to ship a patch
> >>>>> release. At
> >>>>> that point we use the rule of thumb "aim for no more than 1 patch
> release
> >>>>> per minor per month" to guide our community discussion.
> >>>>>
> >>>>> I would like to see more discussion on the community impact of
> increasing
> >>>>>> the commitment required of a release manager. In the short term it
> >>>> would
> >>>>>> be good for Geode to have someone focused on improving the release
> >>>>> process
> >>>>>> for a longer period of time than a single release. But in the long
> >>>> term,
> >>>>>> people may be less likely to volunteer, and release experience will
> be
> >>>>>> concentrated in fewer members of the community...
> >>>>> Are there more things that could be automated? When I filled the
> role ~1
> >>>>> year ago there was lots of copying and pasting of scripts and I even
> >>>> wrote
> >>>>> one to help validate fixVersions. Although release process automation
> >>>>> should probably be taken to a different discussion, since it's mostly
> >>>>> separate form Anthony's proposal.
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 25, 2020 at 11:06 AM Owen Nichols <onich...@pivotal.io>
> >>>> wrote:
> >>>>>> These concerns make sense. We could satisfy them within our
> existing
> >>>>>> “on-demand” process:
> >>>>>>
> >>>>>> 1) the first time there is a change to backport to support branches,
> >>>>>> propose the patch release. Now we have a branch. Decide as a
> >>>> community
> >>>>>> how urgently it needs to be released vs how long to hold it open for
> >>>>> other
> >>>>>> potential fixes.
> >>>>>>
> >>>>>> Or, we could emphasize the shift in process with bigger changes:
> >>>>>> i. Instead of cutting "release/1.13.0" on May 4, we could instead
> cut
> >>>>>> "support/1.13"
> >>>>>> ii instead of creating "apache-release-1-13-0-main" pipeline, we
> would
> >>>>>> instead create "apache-release-1-13-main"
> >>>>>> iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> >>>>>> released, we could keep it around for 9 months and re-use it for
> >>>>> collecting
> >>>>>> patches and making patch releases during that time.
> >>>>>>
> >>>>>> The community process around deciding how long to gather fixes
> before
> >>>>>> shipping a patch release isn’t any easier either way.
> >>>>>>
> >>>>>> One advantage of our current process is that a release doesn’t
> happen
> >>>>>> until someone volunteers to make it happen. We can do as many or as
> >>>> few
> >>>>>> patch releases as the community is willing -- a release always has a
> >>>>>> champion.
> >>>>>>
> >>>>>> I would like to see more discussion on the community impact of
> >>>> increasing
> >>>>>> the commitment required of a release manager. In the short term it
> >>>> would
> >>>>>> be good for Geode to have someone focused on improving the release
> >>>>> process
> >>>>>> for a longer period of time than a single release. But in the long
> >>>> term,
> >>>>>> people may be less likely to volunteer, and release experience will
> be
> >>>>>> concentrated in fewer members of the community...
> >>>>>>
> >>>>>>
> >>>>>>> On Feb 25, 2020, at 9:29 AM, Anthony Baker <aba...@pivotal.io>
> >>>> wrote:
> >>>>>>> Here’s a couple things I’d like to avoid:
> >>>>>>>
> >>>>>>> 1) Issuing a patch release for every single commit that we back
> port
> >>>>>> onto a supported minor version. This seems like a high cost
> approach.
> >>>>> Of
> >>>>>> course, some issues may be important enough to require that.
> >>>>>>> 2) Merging a change to develop, and then having to come back weeks
> >>>>> later
> >>>>>> and back porting the change to a release branch. It just seems less
> >>>>>> optimal since I’ll have lost the context on the changes,
> particularly
> >>>> if
> >>>>>> the cherry-pick is non-trivial.
> >>>>>>> More comments below.
> >>>>>>>
> >>>>>>> Anthony
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Feb 24, 2020, at 2:16 PM, Owen Nichols <onich...@pivotal.io>
> >>>>> wrote:
> >>>>>>>> Hi Alexander, currently we don’t start a patch release until
> someone
> >>>>>> proposes a critical fix, which then drives the release (the
> community
> >>>> may
> >>>>>> propose “extra” fixes to tag along once a release branch is cut).
> This
> >>>>>> keeps the process simple, neat and tidy.
> >>>>>>>> Another option I hadn’t thought of is to begin collecting “extra”
> >>>>> fixes
> >>>>>> proactively on a “dormant” branch, so that when someone finally
> >>>> proposes
> >>>>>> releasing a patch, it will already be primed with a bunch of fixes.
> >>>> This
> >>>>>> adds complexity (does a different standard apply to bring fixes to a
> >>>>>> dormant branch? Are release branches separate from support
> branches?
> >>>>> How
> >>>>>> will committers be able to keep track of what is dormant and what is
> >>>>> not?)
> >>>>>>> Why not just either a) keep the release branch alive? Or b) create
> a
> >>>>>> support branch from the release tag?
> >>>>>>>> To implement an N-2 support policy, does it make more sense for
> >>>> Geode
> >>>>>> to make small focused patch releases when needed, or to maintain
> what
> >>>>>> amounts to “3 develop branches at all times”?
> >>>>>>> To me, “develop branch” implies ongoing work. I’m proposing
> “support
> >>>>>> branch” which means only important changes agreed upon by the
> project
> >>>>>> community.
> >>>>>>>
> >>>>>>>>> On Feb 24, 2020, at 11:00 AM, Alexander Murmann <
> >>>> amurm...@pivotal.io
> >>>>>> wrote:
> >>>>>>>>> Thanks for proposing this, Anthony!
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> I don’t think it’s necessary for this proposal to re-define or
> >>>>> clarify
> >>>>>>>>>> what constitutes a critical fix; it sounds like the bar would be
> >>>> the
> >>>>>> same
> >>>>>>>>>> as the standard we already apply when back-porting to release
> >>>>> branches
> >>>>>>>>>> (proposal /w justification, and 3 votes in favor). The only
> >>>>>> difference
> >>>>>>>>>> seems to be that now proposals may list up to three target
> >>>> branches,
> >>>>>> not
> >>>>>>>>>> just one.
> >>>>>>>>>>
> >>>>>>>>> re: Owen
> >>>>>>>>> TL;DR: +1 using the same process as we use for merging critical
> >>>> fixes
> >>>>>>>>> during an ongoing release seems appropriate.
> >>>>>>>>>
> >>>>>>>>> Generally merging a fix to a dormant release branch seems less
> >>>>>> problematic
> >>>>>>>>> than merging a fix to an active release branch where a merge will
> >>>>>> reset all
> >>>>>>>>> release work that has already happened. The cost of merging to a
> >>>>>>>>> dormant release branch is much lower than merging to one that's
> >>>> being
> >>>>>>>>> actively released. Ideally we could just do a PR to merge fixes
> >>>> back
> >>>>> in
> >>>>>>>>> most cases. Unfortunately, I believe it's unreasonable to expect
> >>>> that
> >>>>>>>>> everyone will be aware at all times what's actively being
> released
> >>>>> and
> >>>>>>>>> what's not => Let's pretend we are always shipping these
> branches.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Feb 21, 2020 at 7:35 PM Owen Nichols <
> onich...@pivotal.io>
> >>>>>> wrote:
> >>>>>>>>>> Thank you Anthony for proposing this “N-2” support policy. It
> >>>> isn’t
> >>>>>> a big
> >>>>>>>>>> change, but it is helpful to know that the Geode PMC will now be
> >>>>>> standing
> >>>>>>>>>> behind (and ready to vote on) patch releases within a 9-month
> >>>>> window.
> >>>>>>>>>> Overall, this sounds much like how 1.9.1 and 1.9.2 started as
> >>>>>> community
> >>>>>>>>>> proposals, found a release manager, and went on to be
> successfully
> >>>>>> released.
> >>>>>>>>>> I don’t think it’s necessary for this proposal to re-define or
> >>>>> clarify
> >>>>>>>>>> what constitutes a critical fix; it sounds like the bar would be
> >>>> the
> >>>>>> same
> >>>>>>>>>> as the standard we already apply when back-porting to release
> >>>>> branches
> >>>>>>>>>> (proposal /w justification, and 3 votes in favor). The only
> >>>>>> difference
> >>>>>>>>>> seems to be that now proposals may list up to three target
> >>>> branches,
> >>>>>> not
> >>>>>>>>>> just one.
> >>>>>>>>>>
> >>>>>>>>>> I also don’t think it’s necessary to alter our current process
> to
> >>>>>> maintain
> >>>>>>>>>> a standing "support/x.y" branch. The proposal states that patch
> >>>>>> releases
> >>>>>>>>>> will be “ad-hoc (as needed)”. Our current process serves this
> >>>> quite
> >>>>>> well:
> >>>>>>>>>> we propose a patch release at the time it is needed, then get a
> >>>>>> release
> >>>>>>>>>> manager and create a release branch specifically for that
> release
> >>>>>> (e.g.
> >>>>>>>>>> release/1.9.2 was created from the rel/v1.9.1 tag), then clean
> up
> >>>>>>>>>> afterwards so no unattended pipelines or branches linger.
> >>>>>>>>>>
> >>>>>>>>>> The rotating release manager role has been a hallmark of the
> Geode
> >>>>>>>>>> community process, so I hope this proposal will not dissuade
> >>>> anyone
> >>>>>>>>>> interested in helping with a release. However, getting the
> >>>>> automation
> >>>>>>>>>> improvements we need will require some continuity over several
> >>>>>> releases. I
> >>>>>>>>>> would love to volunteer for this!
> >>>>>>>>>>
> >>>>>>>>>> -Owen
> >>>>>>>>>>
> >>>>>>>>>>> On Feb 21, 2020, at 5:30 PM, Anthony Baker <aba...@apache.org>
> >>>>>> wrote:
> >>>>>>>>>>> Hi everyone,
> >>>>>>>>>>>
> >>>>>>>>>>> I'd like to propose shipping patch releases of Geode as a way
> to
> >>>>>>>>>>> improve our engagement and support of our user community.
> Please
> >>>>>>>>>>> review the details in the linked RFC [1] and kindly offer your
> >>>>>>>>>>> thoughts in this thread.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Anthony
> >>>>>>>>>>>
> >>>>>>>>>>> [1]
> >>>>
> https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases
> >>>>>>>>>>
> >>>>
> >>>> --
> >>>> -John
> >>>> Spring Data Team
> >>>>
> >>>
> >
>
>
--
-John
Spring Data Team
