f these changes limit themselves to
a single line.
From: Owen Nichols
Sent: Tuesday, January 25, 2022 20:18
To: dev@geode.apache.org
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198
with those
changes.
From: Raymond Ingles
Sent: Wednesday, January 26, 2022 10:16 AM
To: dev@geode.apache.org
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198ae374101221c02039c70a561
BTW, just to clarify, when I officially proposed c
apache.org
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198ae374101221c02039c70a561
BTW, just to clarify, when I officially proposed cutting the branch, I hadn't
intended to volunteer as release manager this round. That said, it's important
to branch at a point we're confi
25, 2022 20:18
To: dev@geode.apache.org
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198ae374101221c02039c70a561
Even a small change can have subtle but important effects only
discovered after a long time, so leaning on commit-size as a proxy for risk may
ngle
line.
From: Owen Nichols
Sent: Tuesday, January 25, 2022 20:18
To: dev@geode.apache.org
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198ae374101221c02039c70a561
Even a small change can have subtle but important effects only discovered
after a lon
after it and deciding which need to be in
the 1.15 release.
From: Alexander Murmann
Sent: Wednesday, January 26, 2022 7:21 AM
To: dev@geode.apache.org
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198ae374101221c02039c70a561
Owen, I really
: Tuesday, January 25, 2022 20:18
To: dev@geode.apache.org
Subject: Re: Proposal: Cut 1.15 release branch from SHA
8f7193c827ee3198ae374101221c02039c70a561
Even a small change can have subtle but important effects only discovered after
a long time, so leaning on commit-size as a proxy for risk
Fair point, although my hope is that we continually and incrementally improve
our code base on the /develop branch. Yes, there is an increased cost of back
porting critical changes to support branches but the tradeoff is worth it IMHO.
Anthony
> On Jan 25, 2022, at 11:18 PM, Owen Nichols
Even a small change can have subtle but important effects only discovered after
a long time, so leaning on commit-size as a proxy for risk may only serve to
create a false sense of security.
Also to consider, having a large refactor on develop but not support/1.15 will
increase backporting
A third option, is to cut the branch as normal, and be ready to revert if we
see some kind of issue as we are stabilizing the redis changes
On Jan 25, 2022 17:10, Alexander Murmann wrote:
Hi everyone,
Last week we discussed to cut the 1.15 release branch. I would like to propose
that we cut
Hi everyone,
Last week we discussed to cut the 1.15 release branch. I would like to propose
that we cut the branch from last week's SHA
8f7193c827ee3198ae374101221c02039c70a561. The following commit is a very large
refactor. Nothing obvious seems wrong with that change, but given that we
11 matches
Mail list logo
