Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintaining Predis alive needs community's help #587

Open
nrk opened this issue Oct 27, 2019 · 5 comments

Comments

@nrk
Copy link
Owner

@nrk nrk commented Oct 27, 2019

I bet this won't sound surprising to many long-time users of this library at this point but the time to call for help from the community has finally come, albeit a bit late I guess.

Just a few words on why we've reached this point. Predis has always been mostly a one-man project aside from a few good PRs and various kinds of contributions for which I'm still thankful after years. This didn't pose much issues at least until I started having less and less free time to dedicate to my opensource activity which basically amounted to zero in the last 18 months. Truth to be told part of the problem is also that I don't have the same motivation I had a few years ago to maintain such a library, but I hated to admit it. That said, if there's one thing that fueled my reluctance to call for help is that I've always been quite meticulous with my work (which doesn't mean being perfect, whatever that means) but many PRs I received in the past were admittedly sloppy, with no care for the coding style adopted by the project, glaring errors, conflicts with the overall design of the library or missing tests just to name the most striking examples of what I mean.

So what now? Basically I'm looking for contributors that are seriously interested to help with maintaining Predis and that are willing to strive for the same meticulous approach. I don't expect people rushing here to take up on such task, the fact that Predis is a pure-PHP implementation of the Redis protocol surely attracted critics and in the meanwhile PhpRedis matured so much in terms of features and stability so there's probably less need for it, but I don't want to reach the point of having to mark this project as abandoned because I think it still has its own place in the PHP + Redis ecosystem. Obviously I'll try to help as much as possible especially when there are doubts about Predis internals and the overall design of the library, just don't take readiness for granted due to limited time.

The most urgent task is to rank open issues and fix them to push a new relase in the v1.1 branch, some open PRs address a few of these issues but they probably need some work. At first, contributors willing to help should work on their own forks to polish the code before submitting proper PRs for fixes, but if any currently open PR indeed doesn't need anything more than a merge because it passess the test suite and doesn't break anything else then let me know and I'll merge it ASAP. I may consider giving access to the main repository to contributors that earned my trust, I guess you undestand that I cannot do such a thing immediatly.

The master branch is meant to become v2.0, but since it diverged quite a lot from v1.1 most fixes cannot be easily merged. At first I intended to maintain both v1.1 and master-to-be-v2.0 but in retrospect I guess that plan actually backfired so now the plan is to just fix v1.1 for both implementation bugs and compatiblity issues with newer PHP versions, maybe a few new Redis commands, and leave it at that. On the master branch, aside from applying the same fixes, we should drop support once and for all for PEAR and older PHP versions and rework parts of code that could benefit from new features introduced in PHP 7 before implementing anything new.

I'm not sure how it will go, but let's discuss how to make it work. I'd really prefer to discuss this publicly but if you need to contact me privately then go ahead.

@nrk nrk pinned this issue Oct 27, 2019
@rlunar

This comment has been minimized.

Copy link

@rlunar rlunar commented Oct 28, 2019

Daniele, thank you for sharing your thoughts and be open for contributions; as I mentioned I would like to contribute to bringing back predis back alive, I'm a heavily Redis user and yes PhpRedis would make sense most of the time, but predis allows the no Extension dependency to move ahead with the code in many ways local, serverless, containers; hence my desire to see it moving forward.

@whiteCcinn

This comment has been minimized.

Copy link

@whiteCcinn whiteCcinn commented Nov 6, 2019

Although I am not a big fan of predis, as an open source enthusiast, I do borrow the key prefix design of predis and hope that predis will become better and more modern after the reconstruction.

@renanvieira

This comment has been minimized.

Copy link

@renanvieira renanvieira commented Nov 7, 2019

I don't have much of PHP expertise (I am more proficient and other languages as Python and C#), so I would need some help through the code reviews for the language good practices.

If this is not a problem, would love to help to keep Predis alive.

@srmklive

This comment has been minimized.

Copy link

@srmklive srmklive commented Nov 15, 2019

Danielle, thank you for sharing your thoughts. I have used predis for a lot of projects and would love to be given the chance to help to keep the project alive.

@emmanix2002

This comment has been minimized.

Copy link

@emmanix2002 emmanix2002 commented Nov 16, 2019

I use this library a lot and would love to help out anyway I can. ♥️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.