Please do. We created this repo early on, when we thought .net core made more
sense in it's own repo rather than as part of the native client repo. Since
then, we've decided to put it in geode-native because we frequently have to
update both C bindings and .net core pinvokes at the same time,
ject: Re: Proposal - unprotect develop branch of geode-native
For this situation in Geode repo, in addition to Squash, we also allow Rebase.
This would allow you to put both commits in the same PR to pass checks, but
still apply them to develop as separate commits.
On 8/17/21, 2:20 PM, "Bla
Hello everyone,
Today I once again find myself between a rock and a hard place managing
incoming PRs into the geode-native project. We merged a PR that passed checkin
gates, then broke in the main CI pipeline. Additionally, our code formatter
took an update yesterday, and now disagrees with
+1, only because I only get one vote. Merge commits in develop are a scourge,
IMO, and should be avoided in almost all instances.
Blake
-Original Message-
From: Donal Evans
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash
+1 for draft mode as default. I'm forever switching to it in geode-native
already, because the most convenient way for us to get feedback on build/test
status for all platforms is to run a change through CI, and the only way to do
that is to submit it as a PR.
Thanks,
Blake
-Original
My $0.02 on these:
Things I'd like to see us conform to Google style on:
* I'd be happy to move to C++ 17
* Would also be happy to remove forward declarations. "I'm not a critic, but I
know what I hate," as it were, and I hate forward declarations.
* I would also be happy with an 80-character
Good morning!
We are attempting to push through all of the most longstanding geode-native
PRs, so if you're involved in one as an author or a reviewer your prompt
attention would be much appreciated. There are 4 outstanding that I consider
"very old," all initially submitted prior to the
I suspect it's this job you wished to re-run, yes?
https://concourse.apachegeode-ci.info/builds/14598
As an immediate measure, I've restarted the job with the same inputs.
Thanks,
Blake
-Original Message-
From: Mario Salazar de Torres
Sent: Wednesday, March 17, 2021 9:57 AM
To:
Just FWIW - we cut the 1.14 branch of native *prior to* merging the boost::asio
change, so we would have some mileage on the change before releasing. So, all
other things being equal, this will be in native 1.15, not 1.14.
Thanks,
Blake
-Original Message-
From: Jacob Barrett
Sent:
Hello, may I please have access to the Geode Concourse?
My GitHub username is pdxcodemonkey
Thanks,
Blake
The dotnet-core-client repo is at best a placeholder at present, and is not
suitable for any kind of use. It requires a special build of geode-native that
contains c-style exported API functions, that is only available on a branch on
one of my forks IIRC. It exists under the apache project
Hi Alberto,
I’m back from a week’s vacation this morning, and will have a look.
Thanks,
Blake
From: Alberto Gomez
Date: Monday, November 16, 2020 at 7:11 AM
To: dev@geode.apache.org
Subject: Review for "C++ native client Function.execute() with onServers does
not throw exception if one of
Oops, sorry for the confusion! I’ve been working through Mario’s PRs a lot
lately.
From: Alberto Gomez
Date: Wednesday, October 28, 2020 at 7:10 AM
To: "dev@geode.apache.org" , Blake Bender
Subject: Re: PR process and etiquette
+1 to draft PRs.
By the way @Blake Bender&
+1 for draft PRs. Native has been using these for a few months now, and
they're quite effective. Right now, for example, we have 6 PRs up, 3 of which
are draft. They also turn out to be a convenient way to share work, in certain
circumstances. Mario, for instance, has a draft up for
e some time to give me some feedback on
it?
Thanks for all.
BR,
Mario.
____
From: Blake Bender
Sent: Wednesday, September 30, 2020 4:34 PM
To: dev@geode.apache.org
Subject: Re: PRs to review in geode-native
We'll get on t
We'll get on these today, no worries.
Thanks,
Blake
On 9/30/20, 2:08 AM, "Mario Salazar de Torres"
wrote:
Hi everyone,
I've created 2 PR in geode-native repository:
*
Given that attempts to retrieve metadata after the C++ cache is closed are a
constant headache for Geode Native development, I am generally in favor of
anything that potentially reduces the number of times/places this happens. If
we've failed the handshake, it's very unlikely things will
Smith" wrote:
The main geode repo has a dev-tools directory, that’s a good spot for
scripts. If it’s specific to native client I’d put it in geode-native but if
not the geode repo seems fine.
-Dan
> On Sep 11, 2020, at 1:41 PM, Blake Bender wrote:
>
> Hi all,
Hi all,
I have a Python script I’ve used quite a bit for diagnosing/debugging issues in
geode-native that can decode a whole lot of protocol information from a
debug-level log file. I think it comes in pretty handy, and would like to
share. Just a quick question, though – where’s the right
Working now - thanks, Dan!
On 8/21/20, 12:14 PM, "Dan Smith" wrote:
It looks like they weren’t listed as committers in JIRA. I added them, you
should be able to assign them issues now!
-Dan
> On Aug 21, 2020, at 11:00 AM, Blake Bender wrote:
&
Hello,
In the course of attempting to be a better Geode citizen yesterday, I attempted
to assign a JIRA issue to one of the members of the geode native full-time dev
team, and discovered that I couldn’t. In fact, neither of them (Mike Martell,
Matthew Reddington) can be assigned GEODE JIRA
FWIW, Geode Native works around this by not keeping a separate examples repo at
all. To build our examples, you *must* build your own Geode Native
"installation," which includes the examples tree, or download the desired
tarball/zip file from our GitHub releases.
I’m pretty much agnostic as
Hi Alberto,
I've reached out to Jake to approve his review, then I'll merge this for you.
Sorry for the delay.
Thanks,
Blake
On 7/23/20, 3:08 AM, "Alberto Bustamante Reyes"
wrote:
Hi,
Could someone please take a look at this c++ client PR?
gt; +1 for deleting master branch. An also for updating the wiki page about
>>>> branching that Alberto pointed out.
>>>>
>>>> De: Bruce Schuchardt
>>>> Enviado: viernes, 26 de junio de 2020 17:
Apologies if this has been addressed already and I missed it. In keeping with
other OSS projects, I believe it’s time we did something about removing the
insensitive term master from Geode repositories.
One choice a lot of projects appear to be going with is a simple rename from
master •
Sorry for a long delay, just catching up on a ton of dev mail this morning.
FWIW, I agree that leaving feature/WIP branches in the main repository is bad
practice. The ease and flexibility of branching in Git leads to a strong
tendency towards proliferation of these things, and we really
GitHub Wiki supports Markdown, our current one does not. This means GitHub
wins by default in my book.
Thanks,
Blake
On Thu, Apr 23, 2020 at 8:50 AM Anthony Baker wrote:
> Naba, do you have any updates to share? I’m curious if you have found
> this useful compared to JIRA.
>
> Also, I
Good morning,
We created a repo yesterday for the .net core client work, and the default
branch out of the gate is set to master. I'd like to switch it to develop,
like the rest of the Geode repos, which apparently requires a quick
heads-up and a couple of +1s to go ahead with. So... is
Hello everyone,
I neglected to put an end date on this RFC, but it's been open for 2+ weeks
now, and I believe we're close to (at?) consensus, so I would like to close
it out and move on ASAP. If you still have anything urgent to add, please
reply here and let's hash it out. All other things
t;
> >> On Tue, Mar 31, 2020 at 3:56 PM Jacob Barrett
> wrote:
> >>
> >>
> >>
> >>>> On Mar 31, 2020, at 3:06 PM, Blake Bender wrote:
> >>>
> >>> We in this instance means the native client team. As far as specific
&
We in this instance means the native client team. As far as specific
comments, I'm going to suggest we not go down that road, because this feels
a little more adversarial to me than it needs to be already. Suffice to
say that from my own perspective, in both what you wrote and what I got
from
Just want to make sure I understand what you're after here. We should have
a "ccache" directory or similar in the geode-native repo, where we build C
bindings for the client, then we should compile them into a shared library
containing all of the code, and export/make visible only the C
We’re a little late to the party, but FWIW native client is also a +1.
Mike Martell ran native tests on Windows, and Vince Ford validated it on
Mac.
Thanks,
Blake
On Mon, Mar 30, 2020 at 3:00 PM Ernest Burghardt
wrote:
> It's past the announced deadline and we have enough votes to close the
Just want to +1 on the use of a dynamic library - this really has to be a
shared lib, interop with most other languages demands it. On the other
hand, I'm not a huge fan of making this a separate library from the native
client itself, simply because proliferation of binary files makes life
Hello everyone,
We'd like to add C bindings to the native client, in preparation for the
larger task of adding support for new languages, e.g. .net core. Please
have a look at the proposal below and let me know what you think.
Thanks,
Blake
Hello,
I am attempting to add an RFC to the wiki, and don't appear to have any
kind of write access. Can someone help me out?
Thanks,
Blake
Don't we have a published checklist or guideline or something for this
already? Including stuff like 'always prefix the PR title with a JIRA
ticket #,' etc?
On Mon, Mar 2, 2020 at 8:47 AM Owen Nichols wrote:
> +1
>
> It’s easy to fix too!
>
> On Mon, Mar 2, 2020 at 8:34 AM Jacob Barrett
+1 - this is also a todo item for the native client, I think. NC has a bug
in logging which is in my top 3 for "most irritating," as well, which is
that logging actually starts *before* the logging system is initialized, so
even if you *do* configure a log file, if something happens in NC prior
ivotal.io>
> > > > > wrote:
> > > > > >>>
> > > > > >>> This change to disable all but squash-merge would be really
> easy
> > to
> > > > > >>> revert. How about we try it for a while and see? If people
> d
; > Adopting a common approach across our repos will make it easier for new
> > > contributors to engage, learn our norms, and join our efforts.
> > >
> > > $0.02,
> > > Anthony
> > >
> > >
> > > > On Dec 20, 2019, at 11:32 A
s are
> passing, then the button to click in the Github web UI is "Squash and
> Merge". That's all.
>
> Regards
> Naba
>
>
>
> On Fri, Dec 20, 2019 at 11:55 AM Blake Bender wrote:
>
> > Very well, then, I'll abide by the group consensus but am on
ent team may matter in some contexts but in this
> space we are all GEODE contributors.
>
> Adopting a common approach across our repos will make it easier for new
> contributors to engage, learn our norms, and join our efforts.
>
> $0.02,
> Anthony
>
>
> > On D
Is this a policy the native client team must abide by, as well? It varies
slightly with what we've been doing, and all other things being equal I see
no reason for us to change that. If I am to have any measure of control
over the nc repository, I will definitely enforce a 1:1 correspondence
Transactions are an area of the codebase I've never dealt with, so I'm sure
most/all of what you mention is true. In particular, the only thing I know
about TransactionId is that it's always set to -1, so functionally it's
essentially useless. I'm not certain what all of the implications will be
Please see https://issues.apache.org/jira/browse/GEODE-7302. We have a
ticket to make a decision about whether or not to deprecate a couple of
properties here, and any knowledge of them has long since left the team.
Does anyone have a clue, or informed opinion, as to the importance of
keeping
-1 from native client as well, sorry. RC3 mistakenly picked up an
unnecessary commit, and left out the crash fix I needed. If you revert
commit 5d012199055a9a7657563727f6e26a406b287fc3 and
cherry-pick 55da853760c200c53568fe2e6549c912ec26cc27, "GEODE-7426: Fixes
segfault in log message.", native
Hi Alberto,
I apologize for the mention of gemfire-node-client in OSS Geode JIRA, this
is a proprietary product that you don't have access to. For the time
being, I believe, we have fixed all of the ACE leaks we've found, so
GEODE-7060 can be safely closed.
Just for context, we found that, on
We could also just tag the current NC develop branch. I've run all my
integration tests from NC develop branch against 1.11.0.RC2, and it looks
good on Mac, Windows and Linux.
On Thu, Nov 21, 2019 at 11:25 AM Blake Bender wrote:
> If it's a requirement that the native client runs prope
If it's a requirement that the native client runs properly, I'm a -1.
There's a segfault bug in NC logging (see
https://github.com/apache/geode-native/pull/545), and the release tag is
prior to the fix. I'd prefer to pick up NC from this commit:
Okay I'm convinced we're okay, so switching to a +1. Standard PEBKAC error
here, I managed to produce a native client build which was missing the jar
file we use for a whole bunch of tests, so all failed.
Thanks,
Blake
On Wed, Oct 16, 2019 at 1:03 PM Blake Bender wrote:
> I'm a
I'm a -1 on this one, for the time being, sorry. I ran native client
integration tests against it on my dev workstation and am seeing an
inordinate number of failures. It's gonna take me some time to understand
what's going on, but I'll update everyone shortly as to whether I think we
have a
+1, IMO this really needs to go in.
Thanks,
Blake
On Thu, Sep 12, 2019 at 3:30 PM Anthony Baker wrote:
> My understanding is that this portion of the protocol is determined by
> instanceof checks, not the ordinal version. The messages from the java
> client went through a different code
Looks like this branch was cut prior to Apache updating the RAT version to
0.13. Someone needs to cherry-pick this commit:
https://github.com/apache/geode-native/commit/a58a1d74f398e1acf8b127804d43ea987b8d225d,
and it should be all good.
Thanks,
Blake
On Thu, Aug 29, 2019 at 6:30 PM Travis CI
This looks spurious - apparently a download issue with Apache Rat jar
file. I just ran Rat locally at this Git tag and it passed.
Thanks,
Blake
On Thu, Aug 22, 2019 at 7:33 PM Travis CI wrote:
> Build Update for apache/geode-native
> -
>
> Build: #2059
>
Thanks,
Blake
On Fri, Aug 9, 2019 at 9:05 AM Blake Bender wrote:
> Sorry for the delay on 7019, I'll get it shepherded through ASAP. I'll
> have a look at 7049 today as well.
>
> Thanks,
>
> Blake
>
>
> On Fri, Aug 9, 2019 at 2:24 AM Alberto Gomez
> wrote:
>
>
Sorry for the delay on 7019, I'll get it shepherded through ASAP. I'll
have a look at 7049 today as well.
Thanks,
Blake
On Fri, Aug 9, 2019 at 2:24 AM Alberto Gomez wrote:
> Hi,
>
> I would need some extra reviewers for the following PRs:
>
> GEODE-7019 Idle connections are never closed by
but I don’t know how far
> off latest we are. I don’t think we test anything in an IPv6 context, so I
> would say no that we don’t officially support it in the client. Given some
> time, I could do some testing..
> >
> > Thanks,
> > Mark
> >
> >> On Aug 8,
I'm sure someone will chime in with a more definitive answer, but I'm
pretty certain the answer is no, sorry.
Thanks,
Blake
On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac wrote:
> Hi,
>
>
> can you tell me does geode-native client support ipv6?
>
>
> BR,
>
> Mario
>
FWIW, I pushed the fix yesterday afternoon, so if you rebase to pick it up
LGTM will pass. Thanks for your patience.
Blake
On Thu, Aug 1, 2019 at 9:36 AM Alberto Gomez wrote:
> Having put it this way, I agree with you guys ;-)
>
> Thanks,
>
> -Alberto
>
> On 1/8/19 18:0
I agree with Jake on this one. From a bookkeeping perspective, what I'd
like to see in the history is a single commit that fixes all the LGTM
issues, and your fix for this bug in a separate commit. I have a copy of
your .yml changes on my "fix LGTM" branch already, please back that change
out
on with the rest of the issues. I’m 100% convinced it’s not an issue
with this PR, though - develop branch has the same problem.
Thanks,
Blake
On Wed, Jul 31, 2019 at 7:08 AM Blake Bender wrote:
> Linking errors look like (perhaps among other things) missing symbols for
> libcurl(?)
Linking errors look like (perhaps among other things) missing symbols for
libcurl(?) needed by the Xerces library, which was recently added. We
build internally against RHEL 7, Ubuntu, Windows, and develop on MacBook
Pros, but it appears LGTM is attempting to build on some other OS flavor
and
+1 this needs to happen. I hope that doesn't cause too much pain for the
dev team, but the native client team has a hard requirement that all our
stuff works properly on Windows at all times, and it can cause trouble if
random builds of the server can break us on Windows.
I would hesitate to run
Okay, after a conversation here at the office with folks who know, I can
confirm the answer is "yes," NC has code to copy PDX types in the manner
you're asking after.
Thanks,
Blake
On Tue, Mar 26, 2019 at 8:43 AM Blake Bender wrote:
> Hi Mike,
>
> I'm not 100% certain wh
Hi Mike,
I'm not 100% certain what you're referring to, but... PdxSerializable in NC
has toData and fromData methods that allow you to copy objects via
serialization. That what you're looking for?
Thanks,
Blake
On Mon, Mar 25, 2019 at 12:53 PM Michael Stolz wrote:
> Does this functionality
I can look into the files missing license headers when I get home (probably
in an hour or so). The cmake-build-debug directory is a thing left behind
by JetBrains products, so probably just developer cruft. There’s
apparently a doc change I have to cherry-pick over to the release branch as
well,
+1 for always returning StructSet. Just this change would have pretty
minimal impact. We took a slightly more in-depth look at the code, and it
doesn't look like there's anything preventing us from converting most of
this stuff to standard library code. StructSet could be replaced with
std::map
Hello,
I need to be able to update tickets in Geode JIRA, can someone please set
me up with appropriate permissions?
Thanks,
Blake
68 matches
Mail list logo
