While I share your concern that too many things are getting cherry-picked into 
the release, I disagree that recutting the branch is a good solution. Recutting 
the branch effectively cherry-picks everything on the develop branch. This 
means we start at ground zero evaluating this release. 

Each code change brings risk. We minimize that risk by reducing the change on 
the release branch. The alternative is to “lock” the develop branch, but this 
slows productivity significantly. 

I do think we could do a better job vetting what is and isn’t critical to the 
release though. I would like to see a harder line on new bugs vs. old bugs. 
Fixes to bugs introduced in this release are a clear candidate for including in 
the release. Bugs that have existed for several releases should probably get 
bumped with consideration given for likely or present impact to a user and 
complexity of the issue and fix.

-Jake


> On Aug 26, 2019, at 4:06 PM, Udo Kohlmeyer <u...@apache.com> 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
> 

Reply via email to