I regularly contribute to the documentation, and I support this change. Removal of the experimental Redis module would lighten the burden for those who maintain the Geode documentation.
On Thu, Apr 14, 2022 at 10:39 PM Owen Nichols <onich...@vmware.com> wrote: > Well said, Donal. > > As a past Release Manager, geode-for-redis impacted release timelines for > 1.13, 1.14, and most recently 1.15. I support this proposal in hopes that > refocusing on core Geode makes future releases a little more predictable. > > Now might also be a good time to review other features in Geode that are > marked @Experimental, such as manageability REST API, JDBC connector, > micrometer, SSLParameterExtension, GfshCommand, or AutoBalancer. I hope > this proposal encourages more proposals to either shelve or promote some of > these other experiments. > > From: Donal Evans <doev...@vmware.com> > Date: Thursday, April 14, 2022 at 9:10 PM > To: dev@geode.apache.org <dev@geode.apache.org> > Subject: Re: [discuss] Future of the geode-redis module > I agree with this proposal. > > As someone who has contributed a great deal of time and effort to the > geode-for-redis module in the past year or so, it's sad to see it go, but > realistically, the last thing that Geode needs is more unmaintained code. > Our track record for removing dead or deprecated code is pretty poor, so > removing this before it gets a chance to add to the burden seems like a > sensible idea. In addition to this, the tests in the geode-for-redis module > contribute significantly to the total run time of CI pipeline jobs, > particularly the acceptance tests, in which geode-for-redis tests account > for over 50% of the total run time. > ________________________________ > From: Alexander Murmann <amurm...@vmware.com> > Sent: Thursday, April 14, 2022 5:15 PM > To: geode <dev@geode.apache.org> > Subject: [discuss] Future of the geode-redis module > > Hi Geode community! > > A while ago engineers from VMware started to improve the geode-redis > module that has been in Geode for several years, but never had been > completed. This involved adding more tests for existing functionality, as > well as adding support for more commands. > > VMware will not continue this investment in the geode-redis module. While > the geode-redis module is in a much better place than two years ago there > still is a lot of work left to make it a viable option for most of our > users and the module is still in an experimental state. > > For the community this poses the question of what we want to do with the > existing code. This work now has been started and stopped twice. All code > comes with a maintenance burden which adds up< > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2F&data=05%7C01%7Conichols%40vmware.com%7C446f816dd25e4b44826908da1e95e1f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637855926345514685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rherU8SIujYGLQXkXgIUPCBUtHvMaSy71FQkIvvSWjc%3D&reserved=0>. > Dependencies might need to be updated; flaky tests fixed and it brings > cognitive overhead for us and our users. Unless someone else in the > community steps up to take on the task of maintaining the geode-redis > module, I propose to remove the code from our develop branch and give > everyone more bandwidth to use elsewhere. > > Thank you all in advance for your thoughts >
