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 :smile:

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.

[steveklabnik]

@chrisboulton

First of all, :heart: .

Secondly, I've sent you an invite.

Third, I don't know how composer works, but I would assume that nothing can be released under the original name without your signoff, so hopefully, that is true regardless.

[danhunsaker]

@steveklabnik - Composer would let us use a new name fairly easily if we wanted, but existing users would absolutely need to be told to switch to it, which is problematic. Old packages can be marked as "abandoned" and an alternative suggested, but that's the only real mechanism for indicating alternatives in any official sense.

@chrisboulton - So I guess, then, the question is which repo to push. The changes I merged into my fork are all minor, and most fix bugs. I've also tagged a couple more releases since 1.2, so users can decouple from dev-master. Would you be against starting from that point, or would you prefer to retain the current repo and just have the rest of us help review things?

(We may also want to start using Git Flow, or a variant, to allow more rapid iteration in a sane and stable manner...)

[chrisboulton]

@chrisboulton - So I guess, then, the question is which repo to push. The changes I merged into my fork are all minor, and most fix bugs. I've also tagged a couple more releases since 1.2, so users can decouple from dev-master. Would you be against starting from that point, or would you prefer to retain the current repo and just have the rest of us help review things?

I'd probably lean toward bring them in here. I'd ideally like to tag a 1.3 here in the next short term with whatever else should be the more "final" release before larger and possibly backwards incompatible changes (hello namespaces) are introduced.

[danhunsaker]

@chrisboulton - They're all PRs to this repo, so it should be fairly quick work to address them here. I don't, of course, have repo access here, though. So the exact process from here is pretty much your call.

[chrisboulton]

@danhunsaker: Thanks, I've started to merge things down. Please hold off on resque/php-resque for now though. I'd like to manage that transition.

[rajibahmed]

@chrisboulton and @danhunsaker need any help on documentation or anything else ? and where can chat for improving this project and making it more accessible ?

[schmunk42]

Related :)

• https://github.com/chrisboulton/php-resque/issues/238
• https://github.com/chrisboulton/php-resque/issues/262
• https://github.com/chrisboulton/php-resque/issues/203
• https://github.com/chrisboulton/php-resque/issues/112

[lauripiisang]

https://github.com/chrisboulton/php-resque/issues/274#issuecomment-239999460 @chrisboulton So, you did one merge on that day and now more than a month has passed. Can you at least add the branch with predis and other experimental things? Also, I think resque/php-resque is a great idea so at least someone will perform the merges. @danhunsaker / @steveklabnik, is it possible to make a release from there into packagist, so that @chrisboulton can then have chrisboulton/php-resque suggest resque/php-resque?

[Aeon]

Hi @chrisboulton, of course we understand that life is busy for all of us. That is why people are volunteering to help develop the project. Even after such long time of inactivity, there is still so much interest in the project because your work has truly made life easier for many many people (just in my work projects php-resque has certainly run a few billion jobs by now). If people did not care for it any more, there would not be so many pull requests, so much energy put into it.

We would really really appreciate it if you would be willing to recruit a few of the volunteers in this thread to form a maintainer team. I would be happy to contribute as well. Of course it can be difficult to trust other developers, but after all, we have version control, no mistake is irreversible :)

Perhaps work could be continued on dev branches, and we could schedule one or two days a month to collaboratively review the pull requests and progress with an IRC/Slack/Discord/Gitter chat on the side to reduce latency and get your sign-off? (responsible disclosure: my own pull request that is purely a bug-fix just celebrated its second birthday 🍰).

I understand that there's a few issues that are blocking sign-off on tagging 1.3 - but as long as those issues are only in your head, we can't help with them. Is there a TODO, or any documentation on what remains to be done? I'm sure that more than a few of us would be happy to work on them in order to get it done.

In #262, over a year ago, you said

I want to get the library change into master and in the next release, as Predis is a better library overall.

I do also want to fold php-resque-scheduler into the next release to ensure compatibility (right now there is a nasty compatibility issue which is documented over in that repository and possibly here too). php-resque-scheduler itself needs some tests.

Are these the only two issues that are blocking in your mind? Is there more extensive description of what is necessary to resolve them?

@danhunsaker, do you have any better insight into what work is still needed? Anything we could help with?

[danhunsaker]

A larger maintainer team has been selected, and is simply awaiting the migration to a new namespace to proceed. At Chris's request, that migration is incomplete until he has a chance to properly review things and give his approval. Our impatience, while understandable, valid, and even inevitable in many cases, doesn't affect his personal timetable, as our lives are not his, nor is his ours to command. This is the hardest part of the process, but it will be over soon.

[lauripiisang]

As @Aeon pointed out, I don't see why this project should wait behind one man's personal time. This is version controlled software with a seemingly sensible OSS community behind it, noone's going to force push and release new stuff instantly. @chrisboulton will get his chance to review things and his opinion will be respected accordingly. We can have new PRs merged to some 'resque-phpresque' branch and it'll be good. Waiting indefinitely is begging the shared development for this project to die and continue off in people's personal long-lived forks, removing value from where it should end up in. Just explain this is CONTRIBUTING.md and adhere to it when merging PRs.

[mcfedr]

For those looking to move this project forward, there are quite a few forks already on packagist that have been maintained to various levels. I can certainly link to my own fork that I have linked other projects to, it has a number of the open pull requests from this repo, and fixes from other repos in the network as well as my own. Having said that, I am mostly not interested in being involved in maintenance going forward, as I have mostly stopped using resque in my own projects.

[chrisboulton]

Hello everyone,

Just to update you on what's happening here - over the past week or so you've probably seen me merging down a bunch of pull requests old and new. The intent here is to get ready to cut a 1.3 release, and then figure out where we go from there.

Right now, code pretty close to master is being deployed at @bigcommerce, in an environment where we run approximately 30 million jobs per day. We use both php-resque, and php-resque scheduler, with a couple of extra patches and hooks for our own purposes. Our team are getting this code into our production environment for their own reasons, but at the same time it's also going to let us ensure master is in a state where we can safely cut another stable build.

I'm going to let the code stew in these environments for a little while, and then get a release out the door -- at this point everything I consider required for 1.3 has been merged down. If you have a different opinion, please express it here. The only changes over the coming weeks that I'm comfortable introducing are small patches which are covered with tests.

Chris

[edit] Originally said 10 million jobs a day, however soon realized I was looking at the wrong set of metrics. We push around 33 million jobs a day.

[Aeon]

@chrisboulton, @danhunsaker

Thank you so much for the updates, super happy to see such progress!

Chris, as regards patch proposals for 1.3, would you please consider merging https://github.com/chrisboulton/php-resque/pull/210 - it is a minor bugfix/enhancement, the main thing is that it fixes the job throwing away the started timestamp on call to update. I rebased it off master just now, it should merge cleanly.

Thank you again, and look forward to the new and improved php-resque!

[rolfvreijdenberger]

@chrisboulton and @danhunsaker thanks for the cooperation on this project guys, much appreciated. If any help is needed to get things moving (eg some tests etc) I would be interested to help with that.

[lsloan]

@chrisboulton wrote about a month ago:

I'm going to let the code stew in these environments for a little while, and then get a release out the door -- at this point everything I consider required for 1.3 has been merged down. If you have a different opinion, please express it here.

I'm working on a project that's just starting to use php-resque. We'd like to deploy it to production soon. One of the problems is that the 1.2 release doesn't include the workers code that's mentioned in the README.md. During development, I've been using dev-master via Composer, but that will be a little too risky for production deployment.

While I suppose 1.3 will be released soon, it would have been extremely helpful if there had been some patch-level releases in the interval since 1.2 had been released. At the very least, some releases to make the package work as the documentation suggests.

[rajibahmed]

@lsloan if you are using compose, just use a commit hash on your composer file which suits your need for now.

[schmunk42]

A commit hash does the job, but having several alpha, beta and rc versions is never wrong. We're using that extensively.

[chrisboulton]

@lsloan: As others have suggested, the commit hash is the right way to go.

I like @schmunk42's suggestion though, and I'm happy to get the change log updated and cut a beta release if I can have a few more interested parties for testing? We've been running what's in master for ~1 month now, and have had no issues. I'd like a sample size of > 1, however.

[jaredk2g]

We're running the latest version of Resque master @invoiced with no problems. The only patch we've made is to add support for catching PHP 7 errors (PR in #316).