Re: Native client examples
I agree with Jake that the examples directory should not be part of our official releases. They should be a light-weight entry point to our community, meaning they should be easy to create, modify, and use. While counter-intuitive, in this case, a less official approach to our examples will yield fresher and more helpful examples. On Mon, Oct 23, 2017 at 9:18 AM, Jacob Barrett wrote: > On Fri, Oct 20, 2017 at 6:02 PM Dan Smith wrote: > > > However I do think we should be compiling (and hopefully running!) > > these examples so that they don't rot over time. Especially since I > > believe we are still evolving the native API with breaking changes and > > have not actually managed a release for the native code yet? > > > > If someone in the community has the bandwidth to setup a windows jenkins > build the system requirements and instructions are in the geode-native > README.md. There is a very specific set of toolkit needed to build Geode > Native. After getting Native building you will need to find a way to update > the csproj files with the path to the Apache.Geode.dll before building the > examples solution. I would recommend CMake for that process but a simple > sed replacement works too. > > One option if it is too hard to automate the build of these things in > > geode-examples is that we could put them into geode-native until we > > actually release geode-native. > > > I think it is just fine keeping them where they are. I have very strong > reservations about treating the geode-examples repo as some blessed and > released repository. If it is that strongly coupled with the Geode release > then it should have never been moved to its own repo. Geode Native was put > in its own repo to allow Geode Native to develop and release on an > independent cycle than that of the Geode server and java client. The same > rational was used to support the creation of geode-examples repo. This > should be a living and breathing ground for community based examples. If > ware going to treat it as product and product that is tied to the geode > repo then those components should be moved to the geode repo. > > If the community disagrees then I will gladly move the native examples out > of geode-examples. > > -Jake >
Re: [Discussion] Geode-Native Removing Stats from Public API
Thanks for the clarification Jake. So yes, I'm in agreement that we should simplify the C++ API and remove the stats API from the C++ client. \ah On Mon, Nov 20, 2017 at 10:23 AM, Jacob Barrett wrote: > To clarify, the goal here is to remove access from the public API to inject > custom stats into our stats stream. We would still collect stats for the > internals of the client. > > The rational is multifaceted: > > 1) The C++ API is would need a non-trivial amount of time to modernize. The > current API uses pointers of pointers for maintaining collections. There is > a strange cross relationship between components in the stats classes which > create unique pointer ownership questions. Rather than solving those now > and further dragging out the modernization of the C++ API we would drop it > and evaluated adding it back in a modern way in the future. Though I > suspect adding it back in the future will never happen for the reasons > below. > > 2) The storage format for our stats in proprietary to Geode and lacks wide > market adoption. > > 3) There are no modern tools for analyzing the statistics generated. Geode > lacks a tool for viewing or analyzing the statistics. Unless work is > prioritized on completing the jVSD application then users are forced to > write custom applications to extract the contents of the stats files. > > I support the removal from the Java public API for reasons 2 and 3. Unless > we put a full effort into creating the ecosystem around the stats format to > make it usable we should remove it from the public API. I strongly > encourage that we remove it internally too but that is for another > discussion. > > -Jake > > > On Mon, Nov 20, 2017 at 9:43 AM Michael Stolz wrote: > > > I'm not clear on why we are removing stats gathering capability. > > Do we know that customers aren't using this? > > Is it badly broken? > > > > What is actually driving this work? > > > > -- > > Mike Stolz > > Principal Engineer, GemFire Product Lead > > Mobile: +1-631-835-4771 <(631)%20835-4771> > > > > On Mon, Nov 20, 2017 at 11:42 AM, Bruce Schuchardt < > bschucha...@pivotal.io > > > > > wrote: > > > > > Should this be done for the Java caches as well? > > > > > > > > > On 11/17/17 11:48 AM, David Kimura wrote: > > > > > >> I agree, a statistics interface seems beyond the scope of Geode Native > > >> client responsibility. Hiding or removing seems appropriate to me. > > >> > > >> Thanks, > > >> David > > >> > > >> On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt > > >> wrote: > > >> > > >>> +1 for removal > > >>> > > >>> On Thu, Nov 16, 2017 at 1:46 PM, Jacob Barrett > > >>> wrote: > > >>> > > >>> I want to open a discussion regarding the removal of > StatisticsFactory > > and > > related APIs from the public API. I can't see that we would want the > > Geode > > Native client to be a first class statistics/metrics gathering API. > > There > > are plenty of other first class players in this space. If this > isn't a > > feature of the client then I suggest it be moved internally. It’s > > highly > > unlikely it’s being used but in the case that it is we can consider > > moving > > it back after some serious refactoring as it relies on an over > > abundance of > > raw pointers. Rather than spend time refactoring it now let’s just > > hide > > it > > away. > > > > -Jake > > > > > > > > > > > > > > > >
Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found
Hi Geode Devs, I'm proposing the following change to how we handle deserialization when Domain Objects can't be found and pdx-serialize=false. https://issues.apache.org/jira/browse/GEODE-4367 Looking forward to the discussion. \ah
Request to edit / comment on Geode Confluence
Hi Geode Dev, I would like to comment on a few of the Apache Geode proposals on Confluence. Can someone help me with the permissions? I currently cannot comment. Thank you, Addison
DataEngConf 2018
Hi Apache Geode Community, Wanted to send out a link to a talk I gave at DataEncConf 2018 entitled "What the heck is an In-Memory Data Grid?" The talk highlights Apache Geode and the IMDG space. https://www.youtube.com/watch?v=gAw5MVdIhbQ If you haven't heard of DataEngConf (http://www.dataengconf.com/), I highly recommend attending. The conference organizers really ensure that the conference is for developers first and foremost and that the content focuses on deeply technical topics. All the videos from DataEngConf 2018 can be found here: https://www.youtube.com/user/g33ktalktv/playlists Best, Addison
Re: [VOTE] Time-based release schedule for minor releases
+1 for a cadence based release cycle that using 3-month between minor releases. On Wed, Oct 10, 2018 at 7:29 AM Sai Boorlagadda wrote: > After looking at these definitions are we not talking about time-based > patch releases? > It is again subjective how much functionality makes a MINOR release. > > Though this thread is seeking consensus on time-based scheduled it is > specifically for minors. > it appears to me like we need to update our definitions before we make a > decision on schedule. > > On Tue, Oct 9, 2018 at 10:06 AM Alexander Murmann > wrote: > > > Bruce, agreed. I think we should eliminate all the fluff language around > > "significant improvements". What's "significant" is entirely subjective. > > I'd prefer to stick to the much simpler definition from semver.org: > > > > > > Given a version number MAJOR.MINOR.PATCH, increment the: > > > > > >1. MAJOR version when you make incompatible API changes, > > >2. MINOR version when you add functionality in a > backwards-compatible > > >manner, and > > >3. PATCH version when you make backwards-compatible bug fixes. > > > > > > > > On Tue, Oct 9, 2018 at 9:03 AM Bruce Schuchardt > > wrote: > > > > > -1 > > > > > > To me the definition of major vs minor releases is too muddy. Our > > > Versioning and Branching > > > < > > > > > > https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching > > > > > > > > > page has requirements for a Minor release that seem orthogonal to this > > > discussion. A Minor release "must definitely include significant > > > improvements to current API or components that justify not be > configured > > > (sic) as /maintenance/ changes". > > > > > > The page also describes a Maintenance release that seems to be more > what > > > we're talking about here. > > > > > > I think we need a new proposal for Major / Minor / Maintenance release > > > definitions. That's what we should be voting on. > > > > > > > > > > > > On 10/8/18 2:24 PM, Alexander Murmann wrote: > > > > Hi everyone, > > > > > > > > As discussed in "Predictable minor release cadence", I'd like us to > > find > > > > agreement on releasing a new minor version every three months. There > > are > > > > more details in the other thread and I should have captured > everything > > > > relevant on the wiki: > > > > https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule > > > > > > > > There are also some discussions about patch releases. Let's please > > focus > > > > this vote on the proposed minor release schedule and carry on other > > > > discussions in the [DISCUSS] thread. > > > > > > > > Thank you all! > > > > > > > > > > > > >
Geode Native & Apache Geode 1.8 Release
Hi, The Geode Native components (https://github.com/apache/geode-native) have made tremendous progress since its original donation to Apache. The project is nearing a release candidate and I propose that the *first official release of Geode Native be included in Apache Geode 1.8.* Since donation, the project has - modernized its C++ API based on C++ 11 standards - refactored away the cache singleton to allow for more flexible architectures and client-side data modeling - refactored the serializable interfaces (DataSerializable, PdxSerializable, DataSerializableFixedId) to make object serialization more straight-forward - created several examples on how to use the client ( https://github.com/apache/geode-native/tree/develop/examples) In all, the project has closed 285 JIRA tickets since donation. If you want to learn more about the Geode Native, check out these two Apache Geode By Example videos. .NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4&t=3s C++: https://www.youtube.com/watch?v=KJciEcFRdtY&t=1s Looking forward to hearing your input on including the first cut of Geode Native in Apache Geode 1.8. Best, Addison
Requesting more JIRA permission
Hello Apache Geode Community, I'm writing to request a higher level of permission on JIRA tickets in an effort to increase organization and clarity within our community. As we grow our community and focus our mutual development efforts, it is important to stay organized. For example: - how we organize jira's and sub-jiras - Updating the status of a ticket - What we call the ticket so that it is informative In my daily work on Geode at Pivotal Inc, I find myself wanting to organize things within the community, but don't have the permissions to edit tickets besides by own. I fully recognize that with more ticket permissions comes a greater responsibility to communicate with the community and uphold our democratic model. I will make sure to keep and promote these values. *Please +1 this request if you agree to increase my JIRA permissions so I can edit JIRAs.* Thanks, Addison
Re: Requesting more JIRA permission
ahuddy Not planning any major reorganization of tickets. If that is ever needed, I will make a formal proposal to the community. \ah On Wed, Feb 15, 2017 at 4:52 PM, Dan Smith wrote: > Hi Addison, > > What's your JIRA user id? I can add you. > > Our policy is to give JIRA permissions to anyone that asks, so there's no > need for a vote to give you access. I think we haven't been totally clear > on how people can get access to JIRA and the wiki, sorry about that! I did > recently add a little bit of info to the How to Contribute > <https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute> page > on the wiki to mention that you can email the dev list to ask for this > stuff. > > If you are planning some major reorganization of JIRA tickets, it would be > a good idea to discuss your plans on the dev list first. Contributing to > the clarity and organization of stuff in the JIRA would definitely be > helpful! > > -Dan > > On Wed, Feb 15, 2017 at 4:37 PM, Joey McAllister > wrote: > > > +1 > > > > On Wed, Feb 15, 2017 at 4:36 PM Swapnil Bawaskar > > wrote: > > > > > +1 > > > > > > On Wed, Feb 15, 2017 at 4:29 PM Jared Stewart > > wrote: > > > > > > > +1 > > > > > > > > > On Feb 15, 2017, at 4:27 PM, Michael William Dodge < > > mdo...@pivotal.io> > > > > wrote: > > > > > > > > > > +1 > > > > > > > > > >> On 15 Feb, 2017, at 16:17, Addison Huddy > wrote: > > > > >> > > > > >> Hello Apache Geode Community, > > > > >> > > > > >> I'm writing to request a higher level of permission on JIRA > tickets > > in > > > > an > > > > >> effort to increase organization and clarity within our community. > > > > >> > > > > >> As we grow our community and focus our mutual development efforts, > > it > > > is > > > > >> important to stay organized. For example: > > > > >> > > > > >> - how we organize jira's and sub-jiras > > > > >> - Updating the status of a ticket > > > > >> - What we call the ticket so that it is informative > > > > >> > > > > >> In my daily work on Geode at Pivotal Inc, I find myself wanting to > > > > organize > > > > >> things within the community, but don't have the permissions to > edit > > > > tickets > > > > >> besides by own. > > > > >> > > > > >> I fully recognize that with more ticket permissions comes a > greater > > > > >> responsibility to communicate with the community and uphold our > > > > democratic > > > > >> model. I will make sure to keep and promote these values. > > > > >> > > > > >> *Please +1 this request if you agree to increase my JIRA > permissions > > > so > > > > I > > > > >> can edit JIRAs.* > > > > >> > > > > >> Thanks, > > > > >> Addison > > > > > > > > > > > > > > > > > > >
