New maintainer / financial support
ZimbiX opened this issue · 22 comments
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
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. 👍🏻
Any news on the maintenance topic?
@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?
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?
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.
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.
@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. 😢
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! 😊
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.
@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
@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!
Yes sure, make sure to have 2FA enabled :)
Also - can you write a short message in the discord server (I can give you permissions to write in the #announcement) + create a github release? Thank you very much!
Thanks! No worries. Yeah, can do
@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!
@siegy22 thanks for doing that and sorry for the hassle but can you please invite me to the team again? Unfortunately I missed the original invite and the link has since expired.
Is it also possible to give either @jpaulgs or @smontanari, our tech leads, the ability to manage permissions within the team? I'm not sure if this is possible without making them admins of the que-rb organisation. We'll inevitably have to change permissions in the future so doing so would allow us to handle those changes internally without having to bother you each time.
I changed @jpaulgs and @smontanari to be Owner of the que-rb org now. This way they can invite new people to the team and also delete them when they leave GreenSync for example. 😄
I think we can safely close this issue at this point. GreenSync will help maintain/release que from now on. 💚
Thank you @siegy22, much appreciated 🙌