Capistrano maintainership

[Jonathan Weiss]

Cheers,

You all probably read the sad news, Jamis is stepping down as the
Capistrano and Net::SSH maintainer. Capistrano and the accompaning tools
are essential to many deployment setups and it would be sad to see
Capistrano die.

Mathias Meyer and I are quite familiar with the Capistrano code base (we
wrote Webistrano, Macistrano, and a couple of smaller extensions). We
can see ourselves taking over maintainership for Capistrano and Net::S*.

We already have some small extensions and patches that we could bring in
and would be happy to keep Capistrano alive.

If you are also interested in continuing the development of Capistrano,
feel free to post here or get in touch with us.

Jonathan

--
Jonathan Weiss
http://blog.innerewut.de
http://twitter.com/jweiss

[Simone Carletti]

I'm actually working on a couple of Capistrano new features.

I contacted Jamis on January and he gave me some good ideas about how
implement them.
Unfortunately, it seems I finished them too late.

All the features are available in my Capistrano fork on github.
http://github.com/weppos/capistrano
The template_paths one is not finished yet and needs more unit tests.

I've some additional recipes available as a Gist.

Jonathan, I would be more than happy to give an help to ensure
Capistrano is not going to be lost along the way.

Simone

--
http://www.simonecarletti.com/

[sbfaulkner]

+1 (or is it +2 ?)

I don't see anyone else offering, and you are certainly two of the
more qualified candidates :-)

[Karel Minarik]

Hi,

it's great to see you picking it up so soon :)

Capistrano changed the mental model of deployment forever, for lots of
people, inside Rails community and outside of it.

I cannot help with improving the codebase, but would gladly help with
further work on documentation/tutorials, as I did outline couple of
weeks ago here: http://groups.google.com/group/capistrano/msg/654e5e84d45f9098?

One thing I am quite sure of is that Cap needs more docs/tutorials
covering non-Rails/Sinatra/Merb/Ruby deployments. PHP, Python, etc.

Best,

Karel

[Simone Carletti]

Thanks for your feedback Karel!

I agree that Capistrano needs more documentation and I'm happy to hear someone else is available to contribute.
I must confess I didn't notice your message before, I'm going to post a reply at http://groups.google.com/group/capistrano/msg/654e5e84d45f9098

Talking about the future of maintainership, I'm going to contact Jonathan directly to accelerate the process.

It would be wonderful to get a feedback from Jamis about this topic.
I'm a bit concerned about how we can carry on development without the need to force people to change gem name or repository.

-- Simone

On Thu, Feb 26, 2009 at 11:36 AM, Karel Minarik <karel....@gmail.com> wrote:

Karel

[Lee Hambley]

Hi All,

I'm a little suspect of the Webistrano/Macistrano guys taking over development, as I feel particularly that Webistrano limits the capabilities of capistrano and limits it usefulness for non-rails projects.

Whilst there's still a market for simple-one-push rails deploys, with accountability; But I would be hoping for some kind of reassurance that Web/Macistrano would remain separate projects, and would not affect capistrano in any way.

I do feel that someone that knows the Capistrano internals should take over, I'd have volunteered, except my skills lay in using Capistrano, for complex deploys; not particularly in changing internals, and fixing bugs, and those sorts of things.

Whoever takes it over should be prepared to start living in IRC, and start up a drive to get documentation written... and try and drive it as *the* way to handle deployment.

Even since Net::SSH-Multi - my interest in capistrano has slipped a little, as for the most part, my deploys aren't very compatible with the capistrano notion of a single app over a few roles of servers.

I'm looking forward to whatever happens with Capistrano, Jamis has left us with an exceptional bit of code, we owe it to him to make the right decision about where to take it next.

I will be forking copies of the libraries on Github, to make some changes to the way cap logs out to the screen, some things that have come up from time to time on the mailing list, about problems with how, and where capistrano logs, as well as some stuff I want to do with the output to the screen (does that count as logging?) 

Before we all fork-off and make our own changes, I fear that there will be no go-to-guy for a 'right' version of capistrano that scares me a lot, as it raises the barrier to entry far higher than it needs to be... (will_paginate... Vs. mislavs_will_paginate anyone?)

- Lee

2009/2/26 Simone Carletti <wep...@gmail.com>

[Byron Saltysiak]

I think we should go along with the way git should work. Afterall if
you're looking for Jamis' input on the matter you have to look at the
past and he chose the distributed source repo.

Let everyone fork and my guess is we'll see a clear "go-to" repo in a
month or two. It will be the one that is doing the most updates and is
pulling in changes from the other community leaders most often.

Yes, things will be confusing for a little while but would they not be anyway?

Choosing the mainline in the future based on how well the code is
progressing seems more sensible than choosing now. Luckily Git
supports this.

--
Sent from Gmail for mobile | mobile.google.com

Byron

[Gerhardus Geldenhuis]

Hi
I am just glad someone is willing to step in so quickly.

I think capistrano and webistrano is both great products but with an
original focus on ruby/rails applications. I believe that with a bit
of effort ( a bit more in webistrano) it could easily be made to be
more generic. Currently I have to "bend" webistrano a bit to get it
working nicely with our internal deployment methodologies.

I have been working hard to get our specific tomcat/jboss deployments
working well in a loadbalanced 24/7 environment doing simultaneous and
sequential deployments and I am excited about how capistrano has
enabled me to do this and about the future of the tool. I am hopefull
that when I get a chance I can make the tasks I have written a bit
more generic so anyone can use it for tomcat deployments.

There is'nt really that much deployment tools for tomcat so I reckon
that if you could design a good generic deployment strategy for tomcat
together with some generic "load balancer" interfaces to lb's like
modjk and mod_proxy (even F5) you could have a whole new slew of
users. Especially with closer integration with webistrano to simplify
the usage. The single sign on in webistrano is sure to score lots of
points in corporate environments.

Regards

> > reply athttp://groups.google.com/group/capistrano/msg/654e5e84d45f9098

>
> > Talking about the future of maintainership, I'm going to contact Jonathan
> > directly to accelerate the process.
>
> > It would be wonderful to get a feedback from Jamis about this topic.
> > I'm a bit concerned about how we can carry on development without the need
> > to force people to change gem name or repository.
>
> > -- Simone
>

> > On Thu, Feb 26, 2009 at 11:36 AM, Karel Minarik <karel.mina...@gmail.com>wrote:
>
> >> Karel

[Mathias Meyer]

On 26.02.2009, at 12:55, Lee Hambley wrote:

> Hi All,
>
> I'm a little suspect of the Webistrano/Macistrano guys taking over
> development, as I feel particularly that Webistrano limits the
> capabilities of capistrano and limits it usefulness for non-rails
> projects.
>
> Whilst there's still a market for simple-one-push rails deploys,
> with accountability; But I would be hoping for some kind of
> reassurance that Web/Macistrano would remain separate projects, and
> would not affect capistrano in any way.
>
> I do feel that someone that knows the Capistrano internals should
> take over, I'd have volunteered, except my skills lay in using
> Capistrano, for complex deploys; not particularly in changing
> internals, and fixing bugs, and those sorts of things.

I can understand your concerns, but it is not our intention to take
Capistrano and replace it with a combination of Webistrano and
Macistrano. I'm fond of both, but I regularly use just Capistrano
myself, and work on lots of projects that use Capistrano in ways I
hadn't imagined before, and that's totally cool.

Capistrano will always be Capistrano, your one-stop deployment command
line tool, everything else is more like an ecosystem surrounding
Capistrano. We certainly have ideas where we'd like to take a
Capistrano 3, but it will not be a big union of a web gui and a
desktop tool. It will still be a neat command line tool called cap.

> Whoever takes it over should be prepared to start living in IRC, and
> start up a drive to get documentation written... and try and drive
> it as *the* way to handle deployment.
>

That's what we've been doing for the last years, not always in public,
but rest assured that that's what we're going for. As for IRC, I'm
fine with getting on it more often in the future.

> I'm looking forward to whatever happens with Capistrano, Jamis has
> left us with an exceptional bit of code, we owe it to him to make
> the right decision about where to take it next.
>
> I will be forking copies of the libraries on Github, to make some
> changes to the way cap logs out to the screen, some things that have
> come up from time to time on the mailing list, about problems with
> how, and where capistrano logs, as well as some stuff I want to do
> with the output to the screen (does that count as logging?)
>
> Before we all fork-off and make our own changes, I fear that there
> will be no go-to-guy for a 'right' version of capistrano that scares
> me a lot, as it raises the barrier to entry far higher than it needs
> to be... (will_paginate... Vs. mislavs_will_paginate anyone?)
>

That's exactly what we want as well, we won't push ourselves on the
community, for us it just made sense to take on the responsibilities
to be those guys, because we spend a lot of our time working with and
working on Capistrano.

Hope that cleared things up a bit. We obviously proposed our idea to
Jamis before we officially posted anything, and if we go forward with
this, there will still be the same website, the same gem repository
and the same Capistrano.

Cheers, Mathias
--
http://paperplanes.de
http://twitter.com/roidrage

[eibhinn]

As another non-rails capistrano user, keeping it a flexible
commandline
tool is important. Since that seems to be understood, I'm all for
Mathias
and Jonathan stepping up.

Git forks are great for experimentation, but `gem install capistrano`
better know where to go or we'll lose lots of newcomers.

--
Andy

[Lee Hambley]

I agree,

I am going to stay current with documentation, and use this time to familiaris myself with the core, I'd love to take over having cut my teeth supporting in IRC (which I will continue to do)

I'm talking with Jamis now about taking over the capify site, so I can manage that aspect of it... I'll continue to host it as the go-to place, and whatever happens, I will be inviting those in control of the project (and/or its forks) to document & blog about it there... for a start i'm going to clone the existing site, and template to a wordpress blog, as its easy to setup, and my hosting is php-centric.

I would prefer that a simple "gem install capistrano" is the way to go - for now, with the latest patches, I don't think that there's a need to fork it, and start messing with it yet, there actually isn't anything wrong with it... if Jamis could perhaps invite a couple of us as collaborators on GitHub, so we can control the main gem release, that would be ideal... I wouldn't mind access to do that, or at least to accept pull requests on behalf of the community...

This thread is talking a lot of sense, and it really is up to anyone that wants to to step up and make some changes, I've actually recently being working with xmpp4r - and found their site to be a really valuable resource, I think with Capistrano on the verge of forking into a few spin-offs or otherwise... we could learn something from the information provided on their site...

http://home.gna.org/xmpp4r/

I'm still hosting a poll about what we'd like for Capistrano on my blog...

http://lee.hambley.name/2009/02/capistrano-feature-request-poll

If you have an interest, please - I invite you to cast a vote. It is as much for me, and the things I plan to work on so that I can get to know the core better as for grand-plans-for-Capistrano.

Please, continue to discuss, I think we're airing a lot of dirty laundry here and still making good plans for the future of the project.

- Lee

2009/2/26 eibhinn <and...@gmail.com>

[Jamis Buck]

On 2/26/09 2:04 PM, Lee Hambley wrote:
> I would prefer that a simple "gem install capistrano" is the way to go -
> for now, with the latest patches, I don't think that there's a need to
> fork it, and start messing with it yet, there actually isn't anything
> wrong with it... if Jamis could perhaps invite a couple of us
> as collaborators on GitHub, so we can control the main gem release, that
> would be ideal... I wouldn't mind access to do that, or at least to
> accept pull requests on behalf of the community...

I won't be adding anyone as collaborators on my github copy of
Capistrano. That wouldn't help at all with the gem release process,
anyway, which is all done via RubyForge. As I've mentioned elsewhere,
though, once a new version of cap is ready to go, and appears to have
community support, I'll gladly hand over the keys to the rubyforge
project so that gems may be released there.

I'll admit that this part of the transition feels sticky--there's a
danger if more than one team forks cap and both are successful, and both
want to release a new cap gem... I'm counting on that not happening,
though, given that there really wasn't a huge interest in hacking on
capistrano before.

- Jamis

[Lee Hambley]

Hey Jamis,

I never actually bothered to check, I figured it was served from the github gem server -- completely agree with your last statement about people not really taking much interest in hacking the core before, there's no reason that people should go messing with it for no real reason now...

My only concern would be that there is no more single place to go to get a copy, get info and learn about it, a bunch of similarly named forks, with similar feature sets would just cause trouble :)

- Lee

2009/2/26 Jamis Buck <ja...@37signals.com>

[Jamis Buck]

On 2/26/09 2:18 PM, Lee Hambley wrote:
> Hey Jamis,
>
> I never actually bothered to check, I figured it was served from the
> github gem server -- completely agree with your last statement about
> people not really taking much interest in hacking the core before,
> there's no reason that people should go messing with it for no real
> reason now...
>
> My only concern would be that there is no more single place to go to get
> a copy, get info and learn about it, a bunch of similarly named forks,
> with similar feature sets would just cause trouble :)

The only reason people look to "/jamis/capistrano" as the canonical copy
is because that's what's been linked to in the past. As soon as another
repo because the "canonical" one (whatever that means), it becomes a
documentation issue. There's really nothing especially discoverable
about "/jamis/capistrano", and there are already a LOT of capistrano
forks on github, and it never really caused trouble before. :)

- Jamis

[Jonathan Weiss]

Lee Hambley wrote:
> My only concern would be that there is no more single place to go to get
> a copy, get info and learn about it, a bunch of similarly named forks,
> with similar feature sets would just cause trouble :)

I don't think this will happen as the 'blessed' version will pretty fast
become known and linked.

Mathias and I thought about using the 'capistrano' github user as the
main repo. So future releases come from github.com/capistrano/capistrano
and github.com/capistrano/capistrano/net-ssh. Is using the Capistrano
name for this user on Github ok with you Jamis?

We were already contacted by a couple of people and we will try to
assemble their patches and our stuff there over the next couple of days.

[Jamis Buck]

On 2/26/09 2:27 PM, Jonathan Weiss wrote:
> Lee Hambley wrote:
>> My only concern would be that there is no more single place to go to get
>> a copy, get info and learn about it, a bunch of similarly named forks,
>> with similar feature sets would just cause trouble :)
>
> I don't think this will happen as the 'blessed' version will pretty fast
> become known and linked.
>
> Mathias and I thought about using the 'capistrano' github user as the
> main repo. So future releases come from github.com/capistrano/capistrano
> and github.com/capistrano/capistrano/net-ssh. Is using the Capistrano
> name for this user on Github ok with you Jamis?

I'm totally out of this game. :) Play by whatever rules you wish!

- Jamis

[Lee Hambley]

+1 for a capistrano user on github...

Does anyone know what happens, if Rubyforge, and Github gems both exist, which do you end up with... the newest, I suppose?

- Lee

2009/2/26 Jamis Buck <ja...@37signals.com>

[Jamis Buck]

On 2/26/09 2:39 PM, Lee Hambley wrote:
> +1 for a capistrano user on github...
>
> Does anyone know what happens, if Rubyforge, and Github gems both exist,
> which do you end up with... the newest, I suppose?

Github gems are not searched unless you explicitly configure for them.
Furthermore, github gems are prefixed with the username (e.g.
jamis-capistrano, if my cap repo were configured to serve gems).

- Jamis

>
> - Lee
>
> 2009/2/26 Jamis Buck <ja...@37signals.com <mailto:ja...@37signals.com>>

>
>
> On 2/26/09 2:27 PM, Jonathan Weiss wrote:
> > Lee Hambley wrote:
> >> My only concern would be that there is no more single place to go
> to get
> >> a copy, get info and learn about it, a bunch of similarly named
> forks,
> >> with similar feature sets would just cause trouble :)
> >
> > I don't think this will happen as the 'blessed' version will
> pretty fast
> > become known and linked.
> >
> > Mathias and I thought about using the 'capistrano' github user as the
> > main repo. So future releases come from
> github.com/capistrano/capistrano

> <http://github.com/capistrano/capistrano>
> > and github.com/capistrano/capistrano/net-ssh
> <http://github.com/capistrano/capistrano/net-ssh>. Is using the

[Lee Hambley]

Ahh :)

That explains why I could never get my gem to install anywhere :)

[Karel Minarik]

Just a quick note -- I would not be overly worried with some "chaos"
regarding Github forks. It'd be great to see different/separte ideas
implemented.

Of course, there should be http://github.com/capistrano/capistrano/tree/master
as "canonical". Sinatra [http://github.com/sinatra/sinatra/] has it
setup precisely this way...

Karel

[Lee Hambley]

Karel,

Excellent, I have the site from Jamis now, I'll try and find some time to do something with it tonight/tomorrow... I'll ask him to change the nameservers once I'm done setting it up.

- Lee

2009/2/27 Karel Minarik <karel....@gmail.com>

[Mike Bailey]

Capistrano is stable and mature. I can't understand the suggestion
that it might die. What could cause that?

I use Capistrano on a daily basis in my paid work and on personal
projects. I've invested a lot of time writing Cap tasks. I don't want
its behaviour to change and require me to redo that work. With 371618
rubygem downloads from rubyforge to date[1], I suspect there are many
others in my position.

I've included below a listing of the number of commits per contributor
in the git repo. I can't see an *obvious* successor there. I think
Jamis would have told us if he had.

Rather than decide now which fork people should follow, why don't we
take a different approach? Those who are interested in providing gems
could make them available under their username on github. Users who
feel the need can choose a fork based on merit (and recommendations by
people they trust).

They could then install an alternative like so:

sudo gem uninstall capistrano
sudo gem install mbailey-capistrano --source http://gems.github.com
gem which capistrano # =>
/usr/local/lib/ruby/gems/1.8/gems/mbailey-capistrano-2.5.6/lib/capistrano.rb

(Note that I don't currently have any intention of maintaining a gem.
But you can copy the gemspec from my fork if you want to.)

It may well be that mattmatt-capistrano turns out to be the best fork
for the most people. But rather than create capistrano-capistrano on
github, why not let each fork compete on it's merits.

- Mike

maculike2:capistrano mbailey$ git log | grep Author | sort | uniq -c | sort -r
460 Author: Jamis Buck <ja...@37signals.com>
12 Author: Ryan McGeary <ryan...@mcgeary.org>
11 Author: David Heinemeier Hansson <da...@loudthinking.com>
4 Author: esad <es...@esse.at>
4 Author: Mathias Meyer <me...@paperplanes.de>
4 Author: Carlos Kozuszko <cko...@gmail.com>
3 Author: Mark Imbriaco <ma...@imbriaco.com>
1 Author: yan <y...@pritzker.ws>
1 Author: grantr <gr...@nightriot.com>
1 Author: Wincent Colaiuta <w...@wincent.com>
1 Author: Walter Smith <wal...@jacksonfish.com>
1 Author: Tim Harper <timch...@gmail.com>
1 Author: Phillip Goldenburg <phi...@goldenburg.com>
1 Author: Paul Paradise <pau...@gmail.com>
1 Author: Paul Gross <pgr...@gmail.com>
1 Author: Mike Bailey <mi...@bailey.net.au>
1 Author: Mark Zuneska, Daniel Berlinger and Evan Closson
<digital.d...@simonandschuster.com>
1 Author: Lewis Mackenzie <le...@magiclamp.co.uk>
1 Author: Kerry Buckley <kerryj...@gmail.com>
1 Author: Jørgen H. Fjeld <jor...@kompetent.no>
1 Author: Jon Evans <j...@springyweb.com>
1 Author: John Trupiano <jtru...@gmail.com>
1 Author: Jesse Newland <jnew...@gmail.com>
1 Author: Jeff Forcier <je...@bitprophet.org>
1 Author: Geoffrey Grosenbach <bo...@topfunky.com>
1 Author: François Beausoleil <fran...@teksol.info>
1 Author: Fabio Akita <fabio...@gmail.com>
1 Author: David Abdemoulaie <git...@hobodave.com>
1 Author: Dave Turnbull <da...@redcordial.org>
1 Author: Carlos Kozuszko <car...@insignia4u.com>
1 Author: Brendan Schwartz <brendan...@gmail.com>
1 Author: Bob McWhirter <b...@fnokd.com>
1 Author: Ben Lavender <b...@ben.local>
1 Author: Andrew Carter <asca...@gmail.com>


[1] http://gems.rubyforge.org/stats.html

[Mislav Marohnić]

On Fri, Feb 27, 2009 at 18:00, Mike Bailey <mi...@bailey.net.au> wrote:

Rather than decide now which fork people should follow, why don't we
take a different approach? Those who are interested in providing gems
could make them available under their username on github. Users who
feel the need can choose a fork based on merit (and recommendations by
people they trust).

++ 

[Mathias Meyer]

On 27.02.2009, at 18:00, Mike Bailey wrote:

> It may well be that mattmatt-capistrano turns out to be the best fork
> for the most people. But rather than create capistrano-capistrano on
> github, why not let each fork compete on it's merits.
>

Because the result will be people continuously asking which fork to
use. I've seen it happen before, and I was in the position of
wondering what fork to use, it wasn't fun. I'm well aware of backwards
compatibility, and if there should be a Capistrano 3, I'm also aware
that it better not break many things in existing tasks.

While I'm all up for the forking fun on GitHub, I prefer a project
with a stable baseline that people can come back and commit back to.
While I don't imply that whatever I'm creating should be that
baseline, I still prefer a gem install capistrano over a gem install
mbailey-capistrano -s ...., since that's what other users will expect
to work, not everyone like spending their time looking through the
potential candidates on GitHub. Personally, I would neither want to
answer questions to problems with specific forks, nor would I want
users to try all kinds of forks until they find a decent one.

[Byron Saltysiak]

On Fri, Feb 27, 2009 at 12:51 PM, Mathias Meyer
<pomon...@googlemail.com> wrote:
>
> On 27.02.2009, at 18:00, Mike Bailey wrote:
>
>> It may well be that mattmatt-capistrano turns out to be the best fork
>> for the most people. But rather than create capistrano-capistrano on
>> github, why not let each fork compete on it's merits.
>>
> Because the result will be people continuously asking which fork to
> use.

People (for now) should just use the latest stable release from Jamis.

How often do mature projects release anyway? In a few months we'll
know better who's really taking up the effort and should be able to
push another stable release.

--
Byron

[Karel Minarik]

> People (for now) should just use the latest stable release from Jamis.

> (...)

> In a few months we'll know better who's really taking up the effort and should be able to push another stable release.

Precisely. Easy forking & merging back using Git+Github gives probably
best ideas who's up for what...

In the meantime, Cap will work as great as it does today,
"unmaintained", even for "beginners".

Unless someone wants some specific feature, some specific issue with
whatever exotic setup s/he has fixed -- s/he can `sudo gem install
capistrano` and be pushing deploys.

Karel

[Bob Martens]

Just wanted to jump in and say that I would be up to help in any
capacity I can. I can't really code in Ruby worth squat, but I offer
whatever I am able to do.