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 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:
- I'll release gems, correctly version bumbed (semver) for all unreleased code. If it's broken, sorry.
- If people are using Capistrano without locking a known-good version in their Gemfile.
- 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.
- I'll be closing all open issues and pull requests at GH that relate to the v2 branch of the code.
- 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.)
- 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
- 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.
- 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.
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.
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?
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.
Release Manager
ACQUITY GROUP
Part of Accenture Interactive
--
--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com 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 capistrano+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--