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.


Reply via email to