I did a little more reading, and it sounds like we should create an
module-info.java to reserve the proper name for those customers who are
using Java 9+. See this article[1] for a description of what can go wrong
if people start using the automatic package without us having declared a
name. I thin
and PR 390 has been approved and merged
On Thu, Nov 1, 2018 at 5:10 PM Ernest Burghardt
wrote:
> geode-native fixes are in https://github.com/apache/geode-native/pull/390
>
> On Thu, Nov 1, 2018 at 4:06 PM Anthony Baker wrote:
>
>> The geode-native source headers I mentioned in [1] need to be c
geode-native fixes are in https://github.com/apache/geode-native/pull/390
On Thu, Nov 1, 2018 at 4:06 PM Anthony Baker wrote:
> The geode-native source headers I mentioned in [1] need to be cleaned up.
>
> Anthony
>
> [1]
> https://lists.apache.org/thread.html/8c9da19d7c0ef0149b1ed79bf0cecde38f1
The geode-native source headers I mentioned in [1] need to be cleaned up.
Anthony
[1]
https://lists.apache.org/thread.html/8c9da19d7c0ef0149b1ed79bf0cecde38f17a854ecfa0f0a42f1ff0b@%3Cdev.geode.apache.org%3E
> On Nov 1, 2018, at 2:01 PM, Bruce Schuchardt wrote:
>
> This PR has been merged to d
This PR has been merged to develop
On 11/1/18 1:35 PM, Bruce Schuchardt wrote:
I would like to get this PR in the release:
https://github.com/apache/geode/pull/2757
I'm testing the merge to develop now
On 11/1/18 1:18 PM, Sai Boorlagadda wrote:
Sure! agree that we should hold the releases
I would like to get this PR in the release:
https://github.com/apache/geode/pull/2757
I'm testing the merge to develop now
On 11/1/18 1:18 PM, Sai Boorlagadda wrote:
Sure! agree that we should hold the releases unless there is a
critical issue.
This is not a gating issue and the code is alre
Sure! agree that we should hold the releases unless there is a
critical issue.
This is not a gating issue and the code is already committed to develop.
Sai
On Thu, Nov 1, 2018 at 1:03 PM Alexander Murmann
wrote:
> In the spirit of the previously discussed timed releases, we should only
> hold
In the spirit of the previously discussed timed releases, we should only
hold cutting the release for critical issues, that for some reason (not
sure how that might be) should not be fixed after the branch has been cut.
Waiting for features leads us down the slippery slope we are trying to
avoid by
I would like to resolve GEODE-5338 as it is currently waiting for
doc update.
Sai
On Thu, Nov 1, 2018 at 10:00 AM Alexander Murmann
wrote:
> Hi everyone,
>
> It's time to cut the release branch, since we are moving to time based
> releases. Are there any reasons why a release branch should not
And one disclaimer I have to add is that these "--add-opens" are the ones
uncovered by our current set of tests, there might be more needed in areas
that are not covered by our tests. So to say the most, our current jdk11
support is still in beta mode.
On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao
But when I sent the email, the PR page on github stated:
This branch has no conflicts with the base branchMerging can be performed
automatically.
Which, in my understanding means there are no merge conflicts.
Stuff is flaky and that's ok. I just want to know how it's supposed to work
so I know w
1) yes, gfsh script will need to be updated to add these configurations.
2) yes, these ad-opens are required to run geode clients as well. We will
need to document them.
On Thu, Nov 1, 2018 at 10:31 AM Dan Smith wrote:
> A couple of questions:
>
> 1) Are you proposing changing gfsh start server
A couple of questions:
1) Are you proposing changing gfsh start server to automatically add these
add-opens, or are you suggesting users will have to do that?
2) Are these add-opens required for running a geode client?
-Dan
On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg
wrote:
> In case anyon
Hi everyone,
It's time to cut the release branch, since we are moving to time based
releases. Are there any reasons why a release branch should not be cut as
soon as possible?
In case anyone else's email broke the thread, below is a link to the
previous thread in the mail archive for context.
https://markmail.org/thread/xt224pvavxu3d54p
On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao wrote:
> We will need to wrap up this discussion with a decision. Looks like we are
> sk
Well, ServerLauncher may or may not create a CacheServer instance when it
starts a server. A server can be created without a CacheServer, for
instance, when in *Gfsh* `start server --disable-default-server` option is
specified.
In addition, you can always find or get the list of CacheServers (if
Above that, though, in the acquisition of the *geode* resource, we see
/opt/resource/lib/commands/in.rb:23:in `output': *PR has merge conflicts*
(RuntimeError)
from /opt/resource/lib/commands/in.rb:110:in `'
That resource could not then be passed to the lower tasks *rsync_code_down *et
al, resul
We will need to wrap up this discussion with a decision. Looks like we are
skeptical about #4, and it's proven to work with #3 since our current jdk11
pipeline is green with this approach.
Can I propose we do #3 and document the extra configuration needed for
jdk11 for now and then work towards #1
Can you start a thread to figure out where things are at and if we’re ready?
Anthony
> On Nov 1, 2018, at 8:48 AM, Alexander Murmann wrote:
>
> I am happy to take on the role for the 1.8 release.
>
> On Wed, Oct 31, 2018 at 8:58 AM Dan Smith wrote:
>
>> We are coming up on the date where we
I am happy to take on the role for the 1.8 release.
On Wed, Oct 31, 2018 at 8:58 AM Dan Smith wrote:
> We are coming up on the date where we said we would start the 1.8 release
> (Nov 1st).
>
> Any volunteers to be release manager for this release?
>
> -Dan
>
I like this but it might be even better if ServerLauncher gave access to
the CacheServer it launched and CacheServer gave access to its cache.
The Locator interface, as well, could have a getCache() method and
deprecate the getDistributedSystem() method. These days a Locator
always has a Cach
In the meantime, a PutMessage is being processed by a P2P message reader
thread. This is a send of a primary put from another server. As part of that
put operation, its delivering the event to a gateway sender which ultimately
causes a VSDCountersManager to be instantiated. This is blocked wait
22 matches
Mail list logo
