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
