Maybe this project needs new maintainer ?

[rajibahmed]

Hi Chris,

I have been using this project in production from 2012. It solved many of our problems. And its a great idea to keep the whole redis compatibility. So, we can use tools already created for ruby.

Unfortunately, the progress and bug fixes are really slow, last two year. I want to propose that you can create a php-resque organization where there are more then one owner or add other developer as maintainer to this project.

This is a useful project, but still it needs to move forward in my opinion.

//Best

[danhunsaker]

+1

[BenoitDD-URIOS]

+1

[scaleupcto]

+1 I'm afraid. We love the library too, but will probably be forced to find something else if we cannot resolve some issues we have. We would be happy to help fix some critical bugs for it.

[bburim]

I think all of us ever did some changes to the original library to fix some bugs which brought us problems. It would be good to join all the efforts and to have one stable repository with all fixes together in one place.

[rajibahmed]

+1 @bburim

[lucups]

+1

[rolfvreijdenberger]

+1. great library and work, thanks for that.
But when moving forward while trying to use the library directly, we cannot work with the velocity for which changes are implemented. we have to resort to using our own fork.

[nataliaAznar]

+1

[fyfey]

+1
PHP definitely needs this, and php-resque is the best solution out there IMHO. I hope someone takes it on soon as this could be even better - and people are clearly happy to contribute by the amount of open pull requests!

[amiri27]

+1
But do we have volunteer for that?

[rajibahmed]

I think we can start with two or three group maintainer based on interest and previous contributions .... (just an idea)

[azngeek]

+1

[HMAZonderland]

Lets fork the project and start there with maintainers.

[razvanphp]

Maybe this can be forked to the official resque namespace, and get maintained there.

CC: @tarcieri @steveklabnik @hone

[steveklabnik]

I would not be totally opposed to giving a port of Resque a repo under the Resque organization. I'm a little uncomfortable starting a fork there, exactly, but it does seem like Chris has checked out. Happens to the best of us; I wasn't exactly a great maintainer of Resque myself.

It seems like he's active on Twitter though; posting a few days ago. Maybe he'll respond there, I'll try tweeting at him.

[danhunsaker]

It needs a lot of work to be brought back up to date with the latest Ruby version, but there does seem to be plenty of interest in that area.

[olliebrennan]

Hi all, it has been a number of months since this thread saw any activity. Is there any movement on reviving this project? It is such a shame to see it become stale like this.

[HMAZonderland]

Perhaps someone should just fork the source and continue from there.

[akkaweb]

This is definitely a great library... however no support made me switch to this https://github.com/josegonzalez/php-queuesadilla .. It works similarly to php-resque and great!

[razvanphp]

@steveklabnik: any news on this one? Can we at least get that fork and see how community responds?

@chrisboulton: any chance we get your ok on this one?

[steveklabnik]

Sure thing, I'm happy to make a repo. Who should have access? this is the tricky question :)

[danhunsaker]

Should we migrate my fork over? I've already merged the active PRs from here into its default branch; it wouldn't take more than a few minutes to switch everything to master instead, update the Composer config with the updated namespace, and have it ready to move..

[zhanggang]

+1 @rajibahmed

[danhunsaker]

Ping @steveklabnik @razvanphp @rajibahmed

As mentioned above, my fork is ready to go as a replacement repo already, if desired. It can already be used directly with Composer as is, but I'm more than willing to migrate it to the Resque namespace at any time.

[rajibahmed]

@danhunsaker the question is will this project be maintained properly after being moved to Resque namespace. Looks like its a question of commitment and shared responsibility.

I may not have the knowledge and time required to maintain the repo but I surely can spend some times on it regularly if needed.

[danhunsaker]

Yeah, it's a bit tricky to give any open source project the time it needs/deserves, especially when it doesn't necessarily directly impact paying work. For my part, I'm more than willing to put in as much time as I can spare to maintaining this project. I've made it a point to at least keep up with comments and discussions here, even when i don't have time for working on the actual code, so if nothing else, PR merging would probably be covered. But I'd still prefer a team of responsible parties, as proposed above, so that no one person can bottleneck the entire project (again).

[rajibahmed]

@danhunsaker count me in for any kind of help you need :)

[danhunsaker]

Re-ping @steveklabnik @razvanphp @chrisboulton

Looks like at least two of us are willing to maintain the new repo...

[steveklabnik]

Sorry all, have been ignoring email hardcore lately.

I have made a new empty repo at https://github.com/resque/php-resque and invited @danhunsaker and @rajibahmed . Please do with it what you will 😄

Anyone else reading this thread, if you'd like commit as well, please let me know.

Let's see how this goes.

[chrisboulton]

Hi,

Apologies - I can make all sorts of excuses as to why I haven't given this repository the attention it needs but at the end of the day - they're just excuses.

To this day, I am still heavily using php-resque in production. We're processing something on the magnitude of several million jobs/events a day using it.

Given how critical php-resque is to a lot of people, I believe a lot of scrutiny should be applied to almost all change sets. Not every proposed change should be merged just because they've implemented something with them.

If this project is moving to the Resque org, I'd ask that I'm included in that list of people that have access, and am involved in the decision/steering of this project going forward. There are a number of changes I'd still like to make to the project.

[scaleupcto]

Isn't it just time to open up this repo to some people with a bit more time to make releases? Or has anyone organised a well-staffed fork?

[kabudu]

@RobotRobot, @slince check out the fork from @danhunsaker . That's the one I switched to!

[slince]

@kabudu hi, it sounds greate! however how to install it from the packagist

[kabudu]

@slince here is a link to the packagist page:

https://packagist.org/packages/danhunsaker/php-resque

[rajibahmed]

As php resque is used by many ppl, we should change maintainer for this project https://github.com/resque/php-resque .... resque organisation has kindly opened its door to accept a stable php-resque ... as a community user. Think we should make all pull request toward https://github.com/resque/php-resque and move on. And we should have a in/formal process for reviewing and voting on a PR

[mkingbe]

@chrisboulton any news regarding this? Currently I do not have trust in this library considering the fact that has multiple issues and pull requests opened with no resolution, also is this debate of maintaining it from 2-3 years ago.
Should I use this in production ?

[kabudu]

@mkingbe use this fork instead: https://packagist.org/packages/danhunsaker/php-resque

[bwegrzyn]

For those looking for PHP queue library with multiple adapters and that is actively maintained, this is a great alternative: https://github.com/php-enqueue/enqueue-dev

I'm currently using this in my projects and it's working beautifully with Redis.

[roynasser]

So almost 1 year has gone by, is there any consensus? I'm sad to see this go to dust :(

an eager community, many users, good product....and yet I think we will have to look elsewhere in order to keep up with php7, and some additional functionality that we want to add...

Is @danhunsaker 's repo being updated at all? (I see its abt 15+ commits ahead and 2 behind here? the 2 behind seems odd, but it may just be git confusion...) . Are we expecting to go into the official resque org? (IMO that makes most sense...)

@danhunsaker have you tested or know about compatibility of your fork with php7? we are starting our migration and php-resque is a big part of getting ready to upgrade...

[kabudu]

@RVN-BR I've moved on from php-resque and now use the library recommended by @bwegrzyn . It does look like php-resque is not moving any further forward. :/

[makasim]

It does look like php-resque is not moving any further forward. :/

I am a maintainer of enqueue library. It is quite matured and stable. @kabudu what kind of movement do you expxect (any issues or PRs) ?

[kabudu]

@kabudu what kind of movement do you expxect (any issues or PRs) ?

@makasim , my comment was related to the discussion history in this issue, such as the many open issues, the 1.3 release which hasn't happened yet, the version of the library in the resque namespace which hasn't seen any movement since it was created etc. I guess my comment was more of a conclusion that the library has been abandoned. I've found that the enqueue library has a more active development roadmap so I've opted to move on.

[makasim]

@kabudu let me know if something needs my attention on enqueue repo.

[pprkut]

I'm going to let the code stew in these environments for a little while, and then get a release out the door

@chrisboulton That was almost two years ago. Does that already qualify as "a little while"?

I realize cutting the release, moving to the resque organization and figuring out how the stewardship of the process should look like going forward is a difficult process. But 2 years?
There's more and more forks with changes for their own requirements which are not getting consolidated back together. The longer this continues the more fragmented the community will get and the harder it will be to bring them all back together.

With all due respect to what you've done for the project in the past, I think it's time to make some decisions.

@danhunsaker, @rajibahmed Any input on how to get things rolling again?

[danhunsaker]

Out of respect for @chrisboulton, I'm planning to wait out the current month (October 2018), then move forward with the migration to https://github.com/resque/php-resque on my own if needed. I'm setting up reminder notifications to ensure I follow through as I write this. Look for movement to resume no later than 10 November.

[roynasser]

Waiting anxiously @danhunsaker

mjphaynes/php-resque seems to have activity already... Other forks also... maybe its best to fork from one of those? (Assuming others are still compatible? We are still running from this repo so it would be great if we can have a smooth transition)

[danhunsaker]

My plan is to use this repo, with mine (which contains many of the PRs originally submitted here) rebased atop it, as the starting point, and pull in other commits from other sources as they come to my attention. I'll be coordinating all this with the other maintainers, along with ensuring they're still on board.

[slince]

@danhunsaker looking forward to that

[makasim]

enqueue/redis would support message redelivery\recovery, delaying, expiration. So it might be a good replacement.

[kabudu]

@makasim would the redelivery be automatic? I use enqueue but still have an issue where messages sometimes do not get processed the first time round.

[makasim]

@kabudu Not sure what you mean by automatic. The message consumption was drastically improved in next major version (0.9).

[danhunsaker]

So my reminders never fired. I'm doing this migration work now.

[danhunsaker]

Just waiting to get access to the resque namespace on Packagist. Apparently somebody else registered their own package there years ago, and then has abandoned it since. 🙃

[danhunsaker]

And we're good! Feel free to migrate over to resque/php-resque now! I'm looking forward to some major improvements as PRs start being moved over to the new home, and merged in!

[Tamce]

I'm wondering whether this repo could be marked as Abandon.

I've never noticed that there is a resque/php-resque before I checked this issue.

[danhunsaker]

It should already be marked as abandoned when using Composer, but you would have had to install or update your dependencies sometime after 02 December 2018 to have Composer warn you about it.

[Tamce]

got it, thanks!