I would like to get GEODE-6369 into the next release but that can be
done in a cherry-pick after I finish testing. The changes are in in
discovery, joining the cluster and in failure detection so they've
needed extensive testing.
On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
I am planning to cut the1.9 release branch today after merging this
PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
Is there anything other than that I should be aware of?
Here is the list of issues that were requested to be included into 1.9.
If there is any plan to merge any of these today let me know and
I can cut the branch after that.
GEODE-6334 - CachePerfStats operation count stats may wrap to negative
values
GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value
GEODE-6369 - Cache-creation failure after a successful auto-reconnect
causes subsequent NPE
GEODE-6391 - Event IDs must be included in the PartitioneRegion messages
GEODE-6404 - review use of computeIfAbsent across the code base
(experimental and dropped)
GEODE-6393 - Replace synchronization lock with AtomicReference for
InternalLocator
-
Sai
On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <sai.boorlaga...@gmail.com>
wrote:
I didn't mean blocking a release but the release process (including
cutting the branch).
I thought there was a consensus about strictly cutting a
branch[1] with our new fixed minor release cadence and
only allow critical fixes.
I assumed that any critical fixes that are allowed onto the
release branch are the ones that are identified on the branch
after it is cut and not the ones that are already known.
Correct me if my understanding is wrong.
[1]
https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <n...@pivotal.io> wrote:
I could not find any DISCUSS mails about not blocking a release. I may be
wrong, I apologize for that but could point me to the mail / documentation
about the release management.
Regards
Naba
On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
sai.boorlaga...@gmail.com>
wrote:
Did we not agreed that we won't be blocking a release to include fixes
as
we are in a fixed release schedule?
On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <amurm...@apache.org
wrote:
Usually I am a proponent of cutting a branch and then fixing things on
there where things are more stable. In this case we seem to have a
large
number of fairly serious concerns. Do we think the cost of putting
this
many fixes on develop + the release branch out-weights the benefit of
less
risk of new issues being introduced?
Thoughts?
Thank you, Sai for taking over!
On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
sai.boorlaga...@gmail.com>
wrote:
I volunteer to be the release manager for 1.9.
Sai
On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
amurm...@apache.org
wrote:
If there are no other takers, I can act as release manager for 1.9
and
will
cut a release branch this week.
On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
amurm...@apache.org
wrote:
Hi everyone!
February 1st is approaching rapidly which means it's almost
time to
cut
the 1.9 release. Who is interested in being the release manager
for
1.9?
Thank you!
