guard / rb-fsevent

FSEvents API with signals handled (without RubyCocoa)

Home Page:https://rubygems.org/gems/rb-fsevent

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Coordinated rename of gems

ioquatix opened this issue · comments

Hi fellow maintainers.

I've recently assumed maintainership of rb-inotify and I'm looking to bring it to 1.0 in the next few months.

I'd like to coordinate with you on this process.

There are three main points I think we should discuss initially

  • Shared test suite - these gems do essentially the same thing on different hardware. What about a shared test suite? e.g. this file is created, was it detected? May require some common high level interface.

  • Renaming the gems. rb-inotify is a poor name. I'm not sure what is better, but I'm thinking it may make sense to nest it within FFI, e.g. ffi-inotify and ffi-fsevent. Thoughts? Ideas? We can keep backwards compatibility - we can make a 1.0 release which includes a compatibility layer for the new ffi- variants. This might also require some involvement from the listen gem authors/maintainers.

  • Shared organisation - I've been trying to contact someone within the guard organisation. I think it would make sense for some kind of shared maintainership. We could either try to go down that road with guard or we could simply create our own org and move all code into it.

Sorry, and I've just assumed you are using FFI, which doesn't appear to be the case.

Well, in any case, I think the rb- naming scheme is pretty crappy and I'm open for ideas.

Perhaps something like os- or sys-, fs-, events.

I've decided it would be best to centralise this discussion with all involved parties. My apologies for spamming your issues. guard/rb-inotify#66