new maintainer for rush

[Adam Wiggins]

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.

Thanks,
Adam

[James Seigel]

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.

Post by Adam Wiggins
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.
Thanks,
Adam

[Diamantini Maurice]

Bonjour Adam,

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?

Cordialement,
-- Maurice Diamantini

Post by James Seigel
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.

Post by Adam Wiggins
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.
Thanks,
Adam

[Adam Wiggins]

Post by James Seigel
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.

Adam

[Michael Frawley]

Post by Adam Wiggins

Post by James Seigel
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
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 :)

Mike

[Adam Wiggins]

Post by Michael Frawley
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:

http://adam.blog.heroku.com/past/2008/8/29/objectoriented_file_manipulation/

Adam

[Joel McCracken]

Rush is one of those projects that I really wish was still active and
maintained.

Are you still looking for a new maintainer?

Post by Adam Wiggins

Post by Michael Frawley
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
http://adam.blog.heroku.com/past/2008/8/29/objectoriented_file_manipulation/
Adam

[Sergey Smagin]

I forked it, update to last ruby, cleanup the code and add some features I
needed. Then I created pullrequest and noone still answered me. I also want
to be a maintainer. Joe McCraken: we can cooperate, if you want.

My pullrequest: https://github.com/adamwiggins/rush/pull/19

Post by Joel McCracken
Rush is one of those projects that I really wish was still active and
maintained.
Are you still looking for a new maintainer

[Joel McCracken]

I'm more than willing to defer to you about it. I would love to see
rush grow, but I don't have a ton of time to work on it!


What direction would you like to take it in?

On Sat, Apr 5, 2014 at 12:12 AM, Sergey Smagin

Post by Sergey Smagin
I forked it, update to last ruby, cleanup the code and add some features I
needed. Then I created pullrequest and noone still answered me. I also want
to be a maintainer. Joe McCraken: we can cooperate, if you want.
My pullrequest: https://github.com/adamwiggins/rush/pull/19

Post by Joel McCracken
Rush is one of those projects that I really wish was still active and
maintained.
Are you still looking for a new maintainer

--
You received this message because you are subscribed to the Google Groups
"rush, the Ruby Shell" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/ruby-shell.
For more options, visit https://groups.google.com/d/optout.