Unsure if this has been mentioned, since I'm still reading through all the responses, but having used Cap almost exclusively for _non-Rails_ projects, and having switched from cap to ansible for a new set of projects, there's a pretty easy translation between the two, in a way that cap and chef/puppet/cfengine don't have ... One thought would be to work with the Ansible guys to develop a set of cap-style modules on top of ansible that would take advantage of all the great things cap can do, but without having to maintain the core of the crazy anymore.
Getting a native Ruby-based module base would both ease the port of cap-specific functionality _and_ make it easier for the cap community to build their own ansible modules. Just a thought. Bug On Sunday, October 6, 2013 1:11:47 PM UTC-4, Lee Hambley wrote: > > Dear List Members, > > I've been experiencing a rather overwhelming level of burnout lately, as > I'm sure many of you regular readers on the list and on Github have > noticed, my patience has grown short, and I'm not the passionate, helpful > chap I once was. (Or at least, that I *once tried to be*) > > I'm not even sure if it's a case of poisonous > people<https://www.youtube.com/watch?v=Q52kFL8zVoM>sapping my energy, or a > more general case of burnout since I run my own > company, and have very little free time. > > I'm considering stepping down from maintaining Capistrano at all, if I had > to pick on a shortlist of reasons, it'd be: > > - I don't use Rails all that much anymore, and many of the problems > people report with Cap are really problems of Rails (i.e the entire > manifest/asset pipeline disaster). When people have problems, I'm not > equipped to diagnose what might be going wrong, as I simply don't deploy > that way. My rails projects are all Rails 4 with no assets, or they are > Rails 3 with the most standard > - I've rewritten Capistrano and it's now a better tool, but I too > cowardly to release it and make it mainstream, as Im afraid it'll destroy > whatever good will for open source I have left when the flood of support > questions inevitably comes in, followed by all the people who are unhappy > with what I've built and feel obliged to tell me how bad I am at software. > - *Ruby Gems is an awful platform.* I feel crushed by the burden for > making things secure, both making things difficult to use wrongly, and > making them safe to use. Ruby Gems makes signing gems overly difficult, > uses non-standard methods, and nobody bothers to validate them anyway. > > Whilst I believe strongly in Capistrano as a general purpose tool for all > people right up to epic scale, where things start to get really bespoke for > companies such as the Twitters and Google. I do think the future of > software deployment is in small, containerised VMs and so-called PaaS, as > what we're all doing right now has to end, some time. > > Non-deterministic deploys of code from (usually) un-tagged source control, > with production environments needing all kinds of eccentric heavy weight > tools to help with mutating assets to solve problems that are mostly a > product of poor framework in the first place design can't go on forever. > > Whilst I think Rails is a great framework (and by and large most users of > Capistrano are Rails users), it's asset pipeline is a poorly thought out > idea which causes a myriad of problems. Whilst I love Ruby as a language, > it's failure to standardise on an interpreter has lead to horrible > situations with people using rvm and rbenv and chruby in production where > things really ought to be more specified. > > These problems are problems of other tools, problems of poor design, and > problems of poor education. People are often using rvm and rbenv in > production environments because Ruby is pathologically difficult to install > correctly on modern Linux distributions; and more often than not people > choose LTS versions of their distribution, and then throw those guarantees > out of the window by replacing system components with bleeding edge > versions of turbo-GC hacked version of their required interpreters. This > wouldn't be a problem, except that it's left up to Capistrano, and by > extension to me to work out all the insane ways people might configure > their repositories and production environments, and interpreter switchers > and try to find a way to make it all work together. So far I've been > holding it together, but I'm starting to fall apart at the seams, and I > don't want Capistrano to fall apart with me. > > To everyone who has contributed code to the 2.x branch, and everyone who > has contributed code to the 3.x branch, in particular Tom Clements and Kir > Shatrov I feel an immense debts of gratitude. To @torrancew on Freenode IRC > (I don't want to use your real name here, and I couldn't reach you to ask > for permission) thank you sincerely for years of patience, and support in > the #capistrano channel. > > For everyone else, I'd appreciate your input, how can I take the load off > myself, how can I find a way to do this better, and build a better tool > that is easier to maintain and easier to release, without the fear of > breaking people's builds? How can I trust someone enough to hand over the > baton if I can't learn to live with this level of stress? > > To anyone who works at Github who reads this, why can't I add a file to > tell people not to open issues on Github for user support, when there's a > perfectly good mailing list here??? > > My next steps: > > 1. I'll release gems, correctly version bumbed (semver) for all > unreleased code. If it's broken, sorry. > 2. If people are using Capistrano without locking a known-good version > in their Gemfile. > 3. I won't be signing Gem releases, it's too painful, and so few > people actually bother verifying Gem signatures, it's simply not worth it. > And I *hate* that. > 4. I'll be closing all open issues and pull requests at GH that relate > to the v2 branch of the code. > 5. I'll be yanking 2.5.15 as it's broken (something about Subversion > flags that I have no way of testing, or verifying, and none of the > proposed > fixes include tests, so I'm rolling back to 2.5.14 which apparently didn't > exhibit this problem.) > 6. I won't be taking any more code for the v2 branch of the code. I > haven't used it for more than a year, it's slow, was broken by some ill > advised merges from someone who was trying to help, but really didn't make > things better > 7. I'll be looking for help with testing things before they are > released. That means, following this release, no release until whoever > contributed the code can verify that it works, and it's spent a while in > beta. > 8. I won't be seen in the IRC channel very often, I can't afford the > time to maintain a presence there, and it's a wasteful medium for helping > people as it's such an unstructured ephemeral stream of data. > > I'll be encouraging everyone I meet to find a better way to deploy > software, using containers, or switching to a language better suited to > deployment, where Gem *bundlers* aren't required to get all the load > paths fixed, and where concatenating a few css files, and minifying > Javascript doesn't take 10 minutes. > > I'll hold the reigns for now, but I need your help to keep going. I need > to know that there are people for whom this project still matters, as the > only people I ever hear feedback from are the disappointed, angry, vocal, > entitled, minority. > > Yours, an exhausted Lee Hambley > > -- > http://lee.hambley.name/ > +49 (0) 170 298 5667 > -- -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en --- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
