The future of this gem?

[evenreven]

acts_as_indexed is abandoned software with no commit in 9 years (not even a dependabot merge), and running tests that depend on AAI has resulted in deprecation warnings for years now. The only reason it works at all is that the Ruby devs have happened to have a loooong deprecation period for Fixnum, but when Ruby 3.2 is released Fixnum will be removed, and tests will start to fail.

Although I've complained about the built-in Refinery search before, it's very simple to set up and very useful. Do you have a roadmap for a future where this stops working? Would you consider a different integration plugin or possibly fork acts_as_indexed just to merge stuff like this?

[anitagraham]

Will have a look...

[parndt]

@evenreven absolutely would consider an alternative or a fork

[evenreven]

I'm not going to maintain a fork of a dependency of this integration, sorry. So you should point this to my fork on github? That doesn't seem like a sound maintenance strategy to me. I can do that on my own project (I already have forks of a few of the Refinery gems because of version mismatches or if I needed to backport a fix, but I don't think that's good enough for official use).

An issue for me is that it's just not possible for me to effectively become a co-maintainer of a lot of Refinery, which seems to be what it takes. I try to contribute issues and occasionally upstreaming bug fixes, but some of it goes nowhere due to your lack of time. I understand that Refinery isn't the top priority of any of you. It's understandable! But it's unclear to me what this integration even does (I assume it's for both public facing and admin views and that the search extension uses it under the hood?),
and it's easier for me to write my own implementation of something else than to maintain this or to make my own gem.

When it comes to the future of Refinery search, I discussed a little bit with Brice in this old thread: refinery/refinerycms-search#64. I tried to help that along by explaining properly that it's a working fix for a massive bug that should have been merged years ago (search currently doesn't work at all with non-ascii characters). Why fix issues when you don't merge or release them (another pain point I've experienced over the years is the lack of releases on rubygems)? That's supposed to be the easy part. 😉

I also think the lack of a real roadmap makes it hard to justify contributing to this project. I'm confused by some of the priorities (graphql and mobility) when so many things don't really work. Wymeditor and acts_as_indexed were both abandoned by their creators nearly ten years ago, and it's a miracle they even work at all (the wymeditor integration feels like it's held together by duct tape by this point). I would love to contribute more, but I don't know where you're going with it and where you want it to go, and that makes it a lot harder.

Example: I'm starting a pilot on my site where I aim to replace the frontend search (to begin with) with pg_search, but since you seem to support mysql (I think?) extracting/upstreaming this would be pointless, even if I can write a working implementation.

I don't mean to be harsh, open source is a thankless job and I'm grateful Refinery even exists. I just think you could get more community contributions with a few tweaks to your maintenance model. Cheers, and thanks for hearing me out!

[parndt]

@evenreven thanks for your thoughts, in general they make sense. I wasn't suggesting you should maintain a fork 😄 and the reason we extracted wymeditor to a separate repo was so that other editors could be integrated because of how (un)maintained it is and how it's always been held together with duct tape 😂.

Why fix issues when you don't merge or release them

Primarily this happens because I/we merge them and then go back to focus on other work or life priorities and forget that it's not pushed to rubygems yet 😬. Whenever someone asks for a release it reminds anyone who can push a gem and a gem usually gets pushed.

Example: I'm starting a pilot on my site where I aim to replace the frontend search (to begin with) with pg_search, but since you seem to support mysql (I think?) extracting/upstreaming this would be pointless, even if I can write a working implementation.

mysql support for everything isn't a huge priority - people can use another extension if they can't use a postgres specific extension.

I don't mean to be harsh, open source is a thankless job and I'm grateful Refinery even exists.

Thanks 👍 after your original message I've also reached out to the maintainer of acts_as_indexed to ask for permission to maintain it & merge PRs & push new gem versions, but as yet I haven't heard back.

[evenreven]

@parndt sorry for the late reply! Thank you so much for engaging with me on this, I really appreciate it. Hope you get a reply from the acts_as_indexed maintainer, would be lovely to at least merge the fixes for the failing tests. The stuff about postgres is noted, I'll see when I have something whether it would work as an extracted gem or not. 👍

(If you've taken over as AAI maintainer, feel free to close this. If not, well, then maybe this can be the place for discussing a future replacement.)

[parndt]

but as yet I haven't heard back.

I have permission now 😄 now I just need to locate the available time