The fix for Geode-6369 has been pushed to develop. This needs to go in
the 1.9 release as it fixes some serious issues in auto-reconnect
including a distributed deadlock.
On 2/15/19 2:15 PM, Sai Boorlagadda wrote:
There are about 8[1] issues in JIRA that are in open/in-progress/re-opened
status for 1.9.0.
Can I request all the devs to reflect JIRA with current status?
[1]
https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
Sai
On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda <sai.boorlaga...@gmail.com>
wrote:
Thanks Dave. I keep a note to include Geode Native.
As we are including only a source release for Geode Native
do we need to create a release branch? Or just tag it?
Though we will eventually be tagging Geode & Geode Examples repos.
So until it gets released I think as a place holder I can go ahead still
create a release branch for Geode Native?
Sai
On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes <dbar...@apache.org> wrote:
Sai,
The Geode 1.8 release included (for the first time) a source snapshot of
the geode-native repo.
As far as I know, the same treatment would be in order for v1.9.
On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <bschucha...@pivotal.io>
wrote:
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!
