I'm in search of a new maintainer for rush; I'm proud of this project
and I use it every day, but I don't have the time to maintain it any
longer. I recently gave away maintainership of RestClient and Pony
which revitalized both of those projects, and I'm hoping to do the
same thing with rush.
If you're interested in maintaining the library, including integrating
some of the great patches that are out there in forks, and potentially
taking it in new directions (like splitting apart the core Rush
library for unix integration from the rushd server daemon for cluster
control), please drop me a line with a little about yourself and what
you'd like to do with it.
I was wondering what your plans were for this product as I have used
it in the past and thought it had some interesting concepts. Do you
believe there is a direction you'd like it to go, or is it just a
maintenance project right now?
I suggest that you post this call on the main ruby forum
I'm sure some admin system would be strongly interested.
(add "ruby for admin system" in the subject).
Perhaps rush could be included in Chef in some form?
-- Maurice Diamantini
Currently it's a maintenance project, but it could potentially go some
more interesting directions if someone came to the helm with fresh
Perhaps the biggest issue right now is that rush is a conflation of
three things that have relatively little to do with each other:
1. A shell with Ruby syntax, which you can use to manipulate files and
processes locally in a more structured way than bash. I use it this
way frequently for things like search-and-replace in files, complex
renaming or copying of large sets of files in recursive directories,
or hunting down and killing processes.
2. A unix integration layer for Ruby that is better and more
consistent than the built-in Ruby classes. We use it heavily
throughout the Heroku codebase for this purpose.
3. A way to control a heterogeneous cluster or remote machines, e.g.
an ssh replacement. This part of it has never really advanced beyond
the proof-of-concept stage - it barely works, although I have heard
reports that some people do use it for this purpose.
I'm not sure what the best way to sort all this out is. One fairly
radical idea, for example, would be to separate the remote cluster
control into its own gem (rushd?), and then rename library to
emphasize that #2 is its strength and its focus. It comes with an
interactive shell (just like restclient, sequel, rails, and many other
ruby libraries), but that's an added bonus, not its main purpose.
In any case, deciding whether to make it a maintenance project or
whether to take it in a new direction would be up to the new
This really nails it. Maybe this should be the tagline on the rush website :)
I explored this subject in detail, looking at some other libraries as
well as stuff from the Python world, in this post: