Ruby-FFI is no longer maintained • Hacker News Board

Re: Ruby-FFI is no longer maintained

#11

Post by [deleted] » Mon, Oct 28, 2013, 4:00 AM UTC

w0rd-driven wrote: post #8

This also seems to be an example of how not to no longer provide support. Close all the issues? Let no one take over? I guess a fork works but I've also seen projects clearly taken over as-is with seemingly "official blessing." I prefer the latter approach or at the very least, keep the thing untouched until someone steps up. I could be late to the party and someone finally got around to saying "tough shit, we're don…

[deleted]

Re: Ruby-FFI is no longer maintained

#12

Post by allr » Mon, Oct 28, 2013, 4:02 AM UTC

More importantly, FFI 1.9.1 was released today (http://rubygems.org/gems/ffi) and completely broke knife-solo, returning a huge stack trace ending with:

You may have encountered a bug in the Ruby interpreter or extension libraries.

reverting back to FFI 1.9.0 did the trick.

Re: Ruby-FFI is no longer maintained

#13

Post by jvoorhis » Mon, Oct 28, 2013, 4:12 AM UTC

This is disappointing. I've created a number of FFI-based projects, and maybe have taken it for granted. I checked the mailing list archives, and did not see any warning signs or calls for new maintainers.

Re: Ruby-FFI is no longer maintained

#14

Post by samstokes » Mon, Oct 28, 2013, 4:13 AM UTC

kawsper wrote: post #2

It could be nice if Rubygems could show which gems that depends on a specific gem. I have a feeling that quite a lot depends on FFI. I know that we depend on FFI, because we use selenium-webdriver, which depends on childprocess, which depends on FFI.

You can tell it for a given project by looking in Gemfile.lock. It shows all the gems you explicitly requested in your Gemfile, and what dependencies each one pulled in.

edit: assuming you're using Bundler, that is. If you're not, fix that first ;)

Re: Ruby-FFI is no longer maintained

#15

Post by byroot » Mon, Oct 28, 2013, 4:53 AM UTC

w0rd-driven wrote: post #8

This also seems to be an example of how not to no longer provide support. Close all the issues? Let no one take over? I guess a fork works but I've also seen projects clearly taken over as-is with seemingly "official blessing." I prefer the latter approach or at the very least, keep the thing untouched until someone steps up. I could be late to the party and someone finally got around to saying "tough shit, we're don…

Yeah it's not great, but I wonder if I don't prefer this over maintainers that let their project die, don't answer PR/issues and never tell they would like someone else to take over.

I mean, I understand that it's part of FLOSS, a maintainer owe nothing to his users, but adding a line to a readme to explicitly say it would be appreciated.

Re: Ruby-FFI is no longer maintained

#16

Post by protomyth » Mon, Oct 28, 2013, 4:56 AM UTC

Does anyone have a clue of why? I looked, and the only weird thing I can see is the restoring of BSD license text to some files.

Re: Ruby-FFI is no longer maintained

#17

Post by edbond99 » Mon, Oct 28, 2013, 5:28 AM UTC

kawsper wrote: post #2

It could be nice if Rubygems could show which gems that depends on a specific gem. I have a feeling that quite a lot depends on FFI. I know that we depend on FFI, because we use selenium-webdriver, which depends on childprocess, which depends on FFI.

There is a list of several gems depending on ffi ( https://www.ruby-toolbox.com/projects/ffi ), mostly system stuff: Popular gems depending on ffi childprocess, rb-inotify, rb-kqueue, rb-fchange, ethon, spoon, minitest-chef-handler, win32-process, libnotify, nfqueue, net-ping, rubypython, sys-cpu, sys-uname, gssapi

Re: Ruby-FFI is no longer maintained

#18

Post by petercooper » Mon, Oct 28, 2013, 5:46 AM UTC

protomyth wrote: post #16

Does anyone have a clue of why? I looked, and the only weird thing I can see is the restoring of BSD license text to some files.

I wonder if this is related to there being an extensive "discussion" on Twitter a few days ago about ffi's LGPLv3 license. One thread to start from: https://twitter.com/bascule/status/393509979711213568 .. one of the concerns much later in the discussion seems to be how ffi changed from BSD to LGPL at some stage.

Re: Ruby-FFI is no longer maintained

#19

Post by petercooper » Mon, Oct 28, 2013, 5:49 AM UTC

jvoorhis wrote: post #13

This is disappointing. I've created a number of FFI-based projects, and maybe have taken it for granted. I checked the mailing list archives, and did not see any warning signs or calls for new maintainers.

This might explain some of it (not the original tweet but go much further down in the discussion with regards to how the licensing was changed): https://twitter.com/bascule/status/393509979711213568

Re: Ruby-FFI is no longer maintained

#20

Post by nnq » Mon, Oct 28, 2013, 6:28 AM UTC

I never understood why aren't more Ruby extensions build on FFI instead of the MRI C extensions way - it would make everything work seamlessly on JRuby or Rubinius or Maglev and would also involve much less work.

...hope someone of the big Ruby backers take this project under their wing.