New maintainer / financial support

[ZimbiX]

Dear current maintainer(s),

We've been using Que (1.0.0.beta4) at @greensync for a couple of years now, and have found it to be an excellent job system. We love the transactional guarantees that Que provides by storing our jobs in the same place as the rest of our data. It's now core to many of our applications. Sadly, it seems that the project has begun to stagnate from a lack of development.

A pertinent example is that a few months ago, we upgraded from Postgres 9.6 to 13, and began encountering frequent ERROR: out of shared memory errors in one application (relevant issue: #290). The fix produced by @jasoncodes (thanks so much!) 9 months ago, whilst it was merged, has disappointingly still not made it into a release. In order to resolve our issue, we had to switch to using Que from its master branch.

It's nearing an eye-watering two years since there was a release - 1.0.0.beta4 on 2020-01-17. With contributions being merged since, why is that? And with 1.x seemingly being the version people are encouraged to use, and do so with much success, is there any particular reason why it's still in beta?

Having to depend heavily on an unreleased version has made our team nervous, and led to a discussion about what we want to do about Que going forward. We'd rather not switch away to something like Sidekick, losing the transactional guarantees.

One of the proposed options is to offer that GreenSync become a maintainer of Que. Whilst we could otherwise contribute PRs without permission to merge, we still wouldn't have confidence in the continuance of the project.

Alternatively, we are considering significant financial support (bounties?) for the project to pay for development time of other contributors to get some issues addressed that are important to us.

Primarily, we'd be interested in:

• Publishing a release, so users can begin to benefit from proper Postgres 12+ support
• Implementing Ruby 3 support

What do you folks think? What would you have a preference for? Or would you prefer assistance in some other way?

I can't promise anything yet, as we haven't come to a decision; but I thought I should ask your thoughts.

Many thanks to all current and past maintainers and contributors.

Cheers,

-Brendan

[bkerley]

I'm more an occasional user than a full-time user, but I've been in this position before (on https://github.com/protobuf-ruby/beefcake ), and it seems like a natural part of the open-source library lifecycle. 👍🏻

[christianrolle]

Any news on the maintenance topic?

[ianterrell]

@siegy22 @ZimbiX — how is this looking?

My organization had used this for a past project and it seemed a good fit for what we were doing on a new project, and I never even thought to check if it's Postgres 13 and Ruby 3 compatible!

I like the Postgres-focused nature of this, but I'm also nervous about the maintenance status of this project and feel like I should move to Sidekiq to be prudent.

I think this approach has a ton of potential and promise and things just need maintained. I'm happy to devote a little time to organization and maintenance if it's helpful. How do we get this project on good footing?

[siegy22]

Hi @ZimbiX and @ianterrell

Sorry for not being too active in this community/project over the past year a lot of things went down in my life and I couldn't really find the time to do anything.

I will publish a release of the current master after merging #285 . That will also include the psql 12 support.

Ruby 3 support topic:
I tried to implement this support during multiple days but didn't find a lot of success because how things are built right now see #303 (comment)
I can push my local branch to be available on the que repository if that helps someone.

In general I think GreenSync becoming a maintainer (having merge/publish permissions) would be reasonable at this time. @ZimbiX Or would you rather prefer some kind of financial support for other maintainers?

[ZimbiX]

Thanks for the response, @siegy22. I hope things have settled down for you a bit now =)

At the moment, we're still in the analysis phase, but it's looking more likely that we'll head down the path of contributing effort rather than money at this stage, afaik. A couple of my colleagues spent some time exploring the codebase last week and I'm meeting with them tomorrow to get across how that went.

Adding us to the que-rb org would be much appreciated - a fair bit cleaner than forking.

I had seen your comment about the args split being necessary - that (or a variant) will probably be the approach we take. Any WIP would be a great starting point; cheers =)

@ianterrell Thanks very much for the offer to help out! I guess we'll have to work out how to organise to be most effective.

[milgner]

Regarding Ruby 3 compatibility: I can report that we're using que with Ruby 3.0.2 with the changes from #302 applied and it's working just fine. It was a fresh code base, though and it's possible that a migration is required when upgrading an older codebase with a pre-existing job queue in the DB.

[siegy22]

@ZimbiX Can you send all the usernames from the GreenSync people so I can add them as maintainers?
Unfortunately i cannot add the whole organization. 😢

[siegy22]

@milgner Do you use positional as well as keyword arguments in your jobs? 😄

[ZimbiX]

@siegy22 Sure. Our developers are:

• @chrisnankervis
• @jpaulgs
• @maddymarkovitz
• @nickburgin
• @oeoeaio
• @smontanari
• @thomasvdpol
• @ZimbiX

Cheers

[siegy22]

I would like to inform @chanks at this point as he was the original author and maintainer.
But I guess he's also glad that people are willing to help and keep this project running and making a final 1.0 release! 😊

[chanks]

Definitely glad! :)

…

On Thu, Nov 4, 2021 at 6:15 AM Yves Siegrist ***@***.***> wrote: I would like to inform @chanks <https://github.com/chanks> at this point as he was the original author and maintainer. But I guess he's also glad that people are willing to help and keep this project running and making a final 1.0 release! 😊 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#313 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACJIGT676ZVXOCX5MQ3TBTUKJMKRANCNFSM5DI4UTGQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ianterrell]

@ZimbiX @siegy22 —

Is the following an accurate summary of plans from the above issue & comments?

Timeline	Release	Description
Soon	1.0.0.beta5	Merge #285, cut from master (includes current Postgres 12+ support)
???	1.0	New Ruby 3 support

Issue #311 is the only active issue for Ruby 3 that I see. Is that the best current place to coordinate this work? I'll add some notes there for now.

[ZimbiX]

@ianterrell Yeah, that or do a release of current master and another after #285's merged (it sounds like there might be something pending with that, but haven't looked into it yet). We could even do another release with basic Ruby 3 support before we do the full-on args/kwargs split.

That issue sounds like a good place.

@siegy22 It's sounding like we (GreenSync) are considering this blocked until we have access btw

[siegy22]

@ZimbiX I invited all of the users above into a separate team inside the que-rb organization.
The team should now have maintain rights on the que repo itself allowing to publish/merge/commit things :)

Let me know if I can help you with anything!

[ZimbiX]

@siegy22 Excellent; thanks! Will do 😁