To clarify what I think might be a misunderstanding here, there is zero
evidence of any kind that the large warning clean-up PR has introduced any
issues, performance-related or otherwise.
For my two cents on cutting the branch at the commit before the big change, I'm
of the same opinion as Robert, that we should cut the branch at HEAD and revert
only if it's determined to be necessary. The changes were broad, but the nature
of the changes were benign and low-risk, being simple, automated refactors of
trivial things like removing unnecessary casts or adding "final" to variables.
I understand the argument that we often don't see all the consequences of a
change until some time after it's been merged, but that argument applies to
every change that gets made, and historically, new features and bug fixes have
a far higher change of introducing problems than automated refactors. The
choice of the warning clean-up change seems based almost entirely on the fact
that it touched a lot of files, not in the actual risk associated with those
changes.
________________________________
From: Raymond Ingles <ring...@vmware.com>
Sent: Wednesday, January 26, 2022 10:16 AM
To: dev@geode.apache.org <dev@geode.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 confident about.
Bisecting a 3K-file change is potentially... complicated. If there's confidence
we can track down the issue(s) quickly, a later branch point would be nice. If
not... probably better to branch at a "not known bad" point.
On 1/26/22, 1:03 PM, "Mark Hanson" <hans...@vmware.com> wrote:
First, I think I would suggest that we have someone cut a branch as
suggested and see how long it actually takes.
Second, I would suggest we define a norm if we want to avoid this in the
future.
Third, I don't really like the risk of having this in, but I have only
heard about performance changes in our performance testing. Is there a specific
defect? I looked at the code changes (not all 3000 files but a chunk) before I
approved them. The changes were mostly dealing with warnings like unboxing etc.
Given that these types of changes are lower risk individually, though obviously
of concern en masse, I would like to see a bug or something before we decide to
increase the work load by branching before the change. I understand that we are
nervous about creating a release, but let's get some data (bugs) to justify the
effort.
Thanks,
Mark
On 1/26/22, 7:21 AM, "Alexander Murmann" <amurm...@vmware.com> wrote:
Owen, I really appreciate your point about the increased cost of
backports by the branches diverging like this. I do wonder how high the cost
will be in practice, given that AFAIK most of these changes limit themselves to
a single line.
________________________________
From: Owen Nichols <onich...@vmware.com>
Sent: Tuesday, January 25, 2022 20:18
To: dev@geode.apache.org <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
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 pain, as many cherry-picks will have
merge conflicts that have to be manually "un-refactored".
On 1/25/22, 5:09 PM, "Alexander Murmann" <amurm...@vmware.com> wrote:
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
frequently only discover very subtle, but important changes to Geode after a
long time, I think that this would allow us to reduce some risk for 1.15 and
its future users and give this large change some time to proof itself on the
develop branch. I'd love to avoid that work entirely, but am concerned that we
only might find out about problems a few weeks from now or worse, after we
shipped.
Another option might be to branch from head and revert the change
on the release branch. I am uncertain which approach will proof less work.
