Fundamentally I also don't have a problem with cherry-picking fixes to a
potential release candidate. My concern is that the amount of fixes that
were cherry-picked.
I also believe that "stabilizing" a release does have some
cherry-picking, BUT the amount of stabilization that we have to apply
has to be within reason and control.
I also understand that there are fixes that we want to include that are
critical. BUT if it takes a month (from cutting to generating an RC) to
get close to releasing, indicates that whatever is in develop is NOT
stable. There were fixes that were included and the cause of the issues
was "due to a recent commit SHA-- XXXX". Which means most likely the
rigor to review and test said bug/issue was not effectively tested.
Finding issues with maps that should have been concurrent maps and lead
memory leaks are distressing. Now there we have code that has been
refactored that we prefer not to release. If we don't want to release
it, why is it in the main develop branch. Imo, only code THAT CAN BE
RELEASED should ever make it to the main branch.
Maybe I am the problem here (again).... Maybe it is I that is concerned
with the quality that is being committed and then glossed over with, it
is ok, we can fix any resulting issues coming from that.
If everybody is happy to release 1.10, then so be it... here is my +0.
But I don't think this approach of cutting a release branch and then
effectively having to maintain to development branches and what commits
are applied to the correct branches is in any way maintainable..
--Udo
On 8/27/19 11:56 AM, Bruce Schuchardt wrote:
+1 for going ahead with the current release/1.10
On 8/27/19 11:31 AM, Dan Smith wrote:
+1 to creating RC1 with the current release/1.10 branch this week.
I don't see a fundamental problem with cherry-picking some targeted and
tested fixes to release/1.10, based on our assessment of the risk to
customers vs. the risk of destabilizing the branch. I think
release/1.10 is
in a good state, and we should go ahead with the release.
-Dan
On Tue, Aug 27, 2019 at 9:28 AM Bruce Schuchardt
<bschucha...@pivotal.io>
wrote:
The "develop" branch has a refactoring of membership code that should
not be included in 1.10. I waited until the release branch was cut to
push these changes.
On 8/26/19 4:06 PM, Udo Kohlmeyer wrote:
Hi there Apache Geode devs,
It has been some weeks since the proposed 1.10 release was cut. We've
gone through a few cycles where we keep on submitting "please include
ticket GEODE-XXX" because it is critical and will break the system.
WHICH in reality tells me that current develop is broken and unstable.
I'm going to suggest that we abandon the current 1.10 release branch.
I cannot shake the feeling that our continuous cherry picking into a
branch will result in either the branch becoming unmaintainable, given
we have only select fixes in the branch OR we end up with a branch
that is more stable than our current development branch, which would
result in us having to rebase the develop branch onto the 1.10 branch.
I propose that once we see the pipeline is clean and green for a solid
we then again attempt to cut 1.10 branch.
We CANNOT continue adding to a branch in order to stabilize it.. It
just means the branch we cut from is unstable. If we cannot cut a
branch from develop without having to have weeks of stabilization
cycles, then our main branch is broken...
Either way, not a good spot to be in.
Thoughts?
--Udo
