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.
Sorry to hear that you are not able to find the time. I can relate! I used to run a project on sourceforge, I ran out of time and hardware to maintain it. I left the industry where it was used unfortunately.
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?
Cheers James.
On Feb 5, 8:52 pm, Adam Wiggins <a...@heroku.com> wrote:
> 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 suggest that you post this call on the main ruby forum (comp.lang.ruby). 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?
> Sorry to hear that you are not able to find the time. I can relate! > I used to run a project on sourceforge, I ran out of time and hardware > to maintain it. I left the industry where it was used > unfortunately.
> 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?
> Cheers > James.
> On Feb 5, 8:52 pm, Adam Wiggins <a...@heroku.com> wrote: >> Hey folks -
>> 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.
On Fri, Feb 5, 2010 at 8:21 PM, James Seigel <sei...@gmail.com> wrote: > 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?
Currently it's a maintenance project, but it could potentially go some more interesting directions if someone came to the helm with fresh ideas.
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 maintainer.
On Tue, Feb 9, 2010 at 2:23 PM, Adam Wiggins <a...@heroku.com> wrote: > On Fri, Feb 5, 2010 at 8:21 PM, James Seigel <sei...@gmail.com> wrote: > > 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?
> Currently it's a maintenance project, but it could potentially go some > more interesting directions if someone came to the helm with fresh > ideas.
> 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.
I think splitting the cluster control out in to a separate gem would be a good move for Rush. I imagine some people take a look at Rush for #2 and get confused with #3, or think they'll be pulling in too much to just have a better interface over the filesystem.
I think Rush is one of the best ruby libraries and I would love to see it be more widely adopted. The standard library for dealing with files is such a mess, yet everyone uses it and memorizes its quirks, or builds their own small (procedural) fileutils module. Maybe one day rush could be in the standard library :)
On Thu, Feb 11, 2010 at 2:41 PM, Michael Frawley <frawl...@gmail.com> wrote: > The standard library for dealing with files is such a > mess, yet everyone uses it and memorizes its quirks, or builds their own > small (procedural) fileutils module.
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:
