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