The future of VCR

[Myron Marston]

Welcome!

I’ve been really surprised at the number of responses I’ve received to my call for new VCR maintainers. Thank you for expressing interest! I wasn’t expecting this many responses and I’m trying to figure out the best way to hand the project off to new maintainers. Hopefully this google group will help facilitate that. If you’re interested in helping move the VCR project forward in any way (whether via small, occasional contributions, fostering the community, or potentially becoming new lead maintainer), please join this group.

What I’d like to see

Up to now VCR has been maintained almost entirely by me. There have been many people who contributed a couple of commits and a small handful who have contributed more than that, but there’s never really been a community of contributors. Moving forward, I’m hoping that there’s a community of contributors so the maintenance burden doesn’t lie with one person. However, I also think it’s important to appoint a new lead maintainer (who has ownership of the github org and ruby gem). My experience from transitioning a past OS project to an entire group of people without appointing a lead maintainer taught me that it’s important to pick a lead person, as the project stagnated with no one taking responsibility for moving it forward.

If you’re interested in becoming lead maintainer, please let me know (privately, if you prefer). I also plan to give people commit access on github who submit a merged PR. I thought about simply picking someone up front to be lead maintainer, but in the past when I’ve put out calls for help with VCR there have been a good number of responses, but little follow up in terms of actual contributions made. “Talk is cheap”, as they say. At some future point, I’ll appoint someone lead maintainer.

I’m a bit worried about is this becoming competitive. I very much don’t want that. Stereotypical “alpha male” behavior won’t be tolerated. I care as much (or more) about finding a lead maintainer who fosters a sense of community and is inclusive and respectful as I do about finding someone who has a deep technical understanding of VCR’s implementation.

I’m hoping this google group can help make this a more cooperative process, by fostering communication between those who are interested in helping with VCR in any capacity.

Where things are at now

The master branch contains some recent changes from @mislav that fix compatibility with Faraday 0.9. I’d like to get that released soon, but the travis build isn’t passing at the moment. Historically, the travis build has had intermittent failures due to timeouts and such since the cucumber features use an integration style that runs both the server and the client side. In the past, these builds have tended to pass when retried. For whatever reason, that’s stopped working. The most recent build is passing on 1.9.2 and 1.9.3 but failing on 1.8.7, 2.0 and 2.1. Getting the back to green (potentially by changing timeout settings, or finding ways to make it more consistent) is the most urgent need at the moment, so if you’re able, please roll up your sleeves and help with that.

Other needs

The issues and PRs could also use some attention. I’m happy to give folks who want to focus on issues and PRs github permissions so they can close issues if needed. Please ask.

VCR could also use a proper website. Anyone want to focus on that?

The main new feature I’d like to see is threadsafety. Unfortunately, it’s highly non-trivial in VCR because VCR has global mutable state and I don’t think there’s anyway to design VCR to avoid it. In all likelihood, this is probably a future feature that’ll go in VCR 3.0 eventually.

VCR 3.0

I don’t have much planned for VCR 3.0. Mostly just removals:

• VCR’s FakeWeb support is deprecated and should be removed (or perhaps moved into an external gem.)
• VCR’s support for Typhoeus 0.4 integration is deprecated and should be removed (or perhaps moved into an external gem).
• There are a handful of other deprecated APIs that should be removed.
• Support for Ruby 1.8.7 should probably be dropped, and perhaps 1.9.2/1.9.3 depending on when VCR 3.0 gets released.
  As mentioned above, threadsafety will require a large amount of change, and given the risk involved in so much change, I’d expect that to go in VCR 3.0 as well.

Thanks, and welcome aboard!

​

[Matt Darby]

I'm excited for this. VCR is a great gem and I hope to help infuse some time and energy into it as part of my job at Rackspace.

[Abdelkader Boudih]

I don't think extraction to external gems is necessary , anyone still using those gems has more stuff to worry about than incompatibility with VCR 3.0.

I'm going to work next week on their removal.

[Myron Marston]

On Thursday, November 27, 2014 1:40:21 PM UTC-8, Abdelkader Boudih wrote:

I don't think extraction to external gems is necessary , anyone still using those gems has more stuff to worry about than incompatibility with VCR 3.0.

I'm going to work next week on their removal.

Removing support for those things before VCR 3.0 would be a SemVer violation as, VCR 2.x has publicly documented that it supports those things.  I think it's a mistake to remove them before work on VCR 3.0 starts, and the timing of that is something that the new lead maintainer will get to decide on.

I put them in my posting above just to lay out the little bit of future roadmap I had in mind for VCR, not to suggest those things should happen now.

Myron 

[Abdelkader Boudih]

I totally agree with this. I wanted to say that i will work on their removal next week and prepare a PR when we bump the major version. 

[george...@gmail.com]

I'm excited myself to help out any way I can as well Myron. I've done talks on VCR before and understand it's many benefits when testing. I'd like to help keep it moving forward!

[Shane Emmons]

I'm glad to pitch in and get us towards a 3.0 release. My biggest strength lies around organizing projects. I've seen the money gem through many a breaking change (and the resulting chaos a major bump seems to always bring).

[chase....@gmail.com]

I'd love to help cut out some of the deprecated stuff and move towards 3.0.

[Tony Miller]

I really love this Gem and don't want to see it rot away. 

Getting the build passing seems like the highest priority. Has anyone had any luck fixing the tests with Ruby 2.1? 

I see the same two failures as CI locally with Ruby 2.1.5: https://travis-ci.org/vcr/vcr/jobs/65705786#L3232

  1) VCR::Middleware::Faraday when making parallel requests works correctly with multiple parallel requests

  2) VCR::Middleware::Faraday when making parallel requests behaves like request hooks the after_http_request hook yields the response if there is one and the second block arg is given

Anyone interested in starting a gitter room or irc channel for this project? Maybe we can try to pair to fix the failing tests together.

[cwoo...@gmail.com]

I'm happy to give it a shot this weekend, Tony.  Still stuck on that last build?

Chris

[Tony Miller]

Chris, that would be great. I haven't had any luck with it.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "vcr-maintainers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/vcr-maintainers/kbRCA7wZCrM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> vcr-maintaine...@googlegroups.com.
> To post to this group, send email to vcr-mai...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vcr-maintainers/f5b5bb0d-92bc-42df-87c6-8c746f546038%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
-Tony Miller
github.com/mcfiredrill
@freedrull
freedrool.us

[Chris Woodrich]

All: I have a fix in place, see PR #500.

PS: Can anyone straighten out TravisCI?

[Nell Shamrell]

Thanks for the call for maintainers!  We use VCR heavily with Chef Supermarket and I'd love to contribute as part of my job at Chef :)

Nell Shamrell-Harrington

[djbe...@gmail.com]

So, what's the current status? Who can merge PR's now? I've got one I'd really like to see merged:

https://github.com/vcr/vcr/pull/512

This adds thread safety, and the tests are green.

Thanks,

Dan

[mik...@zoolutions.se]

Hi,

I believe Crealytics Gmbh could contribute some of my time to help maintain VCR. We make heavy use of VCR here at Crealytics and wouldn't mind giving back on this gem.

[michael....@gmail.com]

I've noticed that a lot of the documentation is outdated for VCR 3. I'd like to help create new docs if possible. 

[Tony Miller]

Some pull requests for documentation would be awesome.

On 12 August 2016 at 02:48, <michael....@gmail.com> wrote:

I've noticed that a lot of the documentation is outdated for VCR 3. I'd like to help create new docs if possible. 

--

You received this message because you are subscribed to a topic in the Google Groups "vcr-maintainers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vcr-maintainers/kbRCA7wZCrM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to vcr-maintainers+unsubscribe@googlegroups.com.
To post to this group, send email to vcr-maintainers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vcr-maintainers/2262fa65-ee24-4e68-8799-012e8e351339%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.