Import articles from bundler blog

_posts/2013-10-12-goodbye-bundler-14-hello-bundler-15.html.markdown

@@ -0,0 +1,13 @@
+---
+title: Goodbye Bundler 1.4, Hello Bundler 1.5
+layout: post
+date: 2013/10/12
+draft: false
+author: Terence Lee
+---
+
+People [have been asking](#) why we jumped from a 1.4 release candidate to a 1.5 one without ever releasing Bundler 1.4.0. The Bundler core team takes releases very seriously and tries to be an example of thoughtful release practices to the Ruby community. Since we follow [standard releases candidate](#) policies, release candidates are automatically under a feature freeze. Each release candidate gets roughly two weeks of testing, and any significant bugfixes result in a new release candidate and the timer starting over. The exact code from the first release candidate with no significant bugs will be the code released as the final version.
+
+When we released [Bundler 1.4.0.rc.1](#) it was missing some important features that we wanted to include. While we could have released 1.4 immediately and started testing 1.5, the 1.4 RC had significant bugs as well. While discussing our options, it became clear that the best way to improve Bundler for all users was to drop the 1.4 release and cut a new 1.5.0 release candidate that included all the features in 1.4.0 and the features we had intended to release in 1.4 originally but missed in the RC. Even though there isn't a 1.4.0, we're excited to bring an even faster Bundler to the community with parallel installs. Please help us test 1.5.0! We've compiled a list of changes in the [what's new section](#) on [Bundler documentation website](#).
+
+Special thanks to [Jacob Kaplan Moss](#) and [Daniel Farina](#) for advising me on this course of action and bringing their sane Python practices with them.

_posts/2013-12-07-the-rumors-of-bundlers-death-have-been-greatly-exaggerated.html.markdown

@@ -0,0 +1,25 @@
+---
+title: The rumors of Bundler's death have been greatly exaggerated
+layout: post
+date: 2013/12/07
+draft: false
+author: André Arko
+---
+
+So this week there was some excitement on [Github](https://github.com/jruby/jruby/issues/1146#issuecomment-29714318), [Hacker News](https://news.ycombinator.com/item?id=6841855), and [Ruby Weekly](http://rubyweekly.com/issues/173) about the news that Bundler will (eventually) be merged into RubyGems. Before that comment, which was a side point on a different topic, the idea of merging the two projects had not been announced or explained. As lead of the Bundler project, I'd like to explain the merger plan, such as it is, and the reasoning behind it.
+
+The underlying motivation is simple: RubyGems and Bundler do a lot of the same things. Installing gems, downloading gems, resolving dependencies, and the like. It's a pretty long list of duplicated functionality. Since the RubyGems team now values many features that started in Bundler, they are also adding them, leading to even more duplicated functionality.
+
+During RubyConf this year in Miami, the Bundler team (represented by Terence Lee and myself) and the RubyGems team (represented by Eric Hodel and Evan Phoenix) met to talk about the increasing duplication. In that meeting, we agreed it made sense to decrease the duplication by merging the RubyGems and Bundler projects into one codebase and one team. Eventually. One day.
+
+But not yet! Because still there's a lot of stuff going on. Bundler and RubyGems already have separate feature road maps for the next 6 months, including things like parallel installation of gems and the new, more efficient index format that I talked about in my [talk at RubyConf](https://www.youtube.com/watch?v=-kyhz_VZMMM). As a result of those plans, the merger work of combining code, tests, teams, and policies is not expected to be done for a year or even two years. At the earliest.
+
+While we're talking about potential changes that are this big, I'd also like to make a point about what this means for Bundler. The Bundler team has taken great pains over the years so that Bundler can be stable, reliable, and dependable. We have also gone out of our way to conform strictly to semantic versioning. This has all been for a simple reason: trust. We want you to be able to trust Bundler. To keep that trust, we are willing to make changes much more slowly and cautiously than many other projects. While we all agree that reducing duplicate work is good, keeping Bundler trustworthy is an even higher priority than combining our work.
+
+Even with the plan to eventually merge projects, Bundler will continue to adhere to semantic versioning. We will continue to run the exhaustive Bundler integration RSpec suite. We will continue working just as hard to make sure Bundler updates are reliable and useful to the entire Ruby community. While everyone involved agrees this merger seems good, it also involves a huge amount of work. At a minimum, we need a unified release process and a functional single codebase, but we haven't even started working on either of those yet!
+
+In the meantime, we are enjoying higher cooperation than ever before between the RubyGems and Bundler projects. We are deliberately sharing both server-side and client-side code for the new index format. The RubyGems team has said they will begin using Bundler's integration tests along side their unit tests.
+
+I'm excited about the idea of sharing work between both projects and eliminating duplicated code. We have a common goal of streamlining and simplifying the work of using gems for everyone in Ruby. Even though we aren't working on merging projects yet, keep an eye out for releases of both Bundler and RubyGems that showcase the work we are cooperating to do together.
+
+And we will be happy to announce the merger once it has happened.

_posts/2014-07-16-bundler-api-outages.html.markdown

@@ -0,0 +1,24 @@
+---
+title: Bundler API outages on July 15 & 16, 2014
+layout: post
+date: 2014-07-16 23:29 UTC
+author: André Arko
+---
+
+In the last couple of days, the Bundler API has seen some downtime: 53 minutes on July 15 and 3 hours  and 16 minutes on July 16. Here's what happened, and how we're working to keep it from happening again in the future.
+
+The Bundler API provides information about specific gems, allowing `bundle install` to run more quickly. Without the API installing multiple gems is much slower, because information about every single gem has to be downloaded, instead of just information about the gems that are needed.
+
+Starting with RubyGems version 2.2.0 (which is included with Ruby 2.1), the `gem install` also uses the API to download gem metadata more quickly. As users upgraded RubyGems (or were upgraded by upgrading their Ruby version), the load on the API slowly started to increase. We are usually able to successfully handle the increased load, but only up to a point. When enough large, slow requests are made simultaneously (some of you have really big Gemfiles!), unanswered API requests started to pile up while the slow requests ran. At that point, the problem snowballs pretty naturally, and the API starts responding very sluggishly, if it even manages to respond at all inside the hard 30 second timeout imposed by Heroku.
+
+This snowball effect happens on occasion, and the solution is often as simple as dropping all the requests in the queue so that incoming requests can be served immediately. Yesterday, that wasn't enough. There were too many requests to handle even after dropping the backed up queue of waiting requests. Adding application servers is extremely straightforward, but there was a problem: the database server had reached its connection limit. If we added any more application servers, we would need additional database connections, and our current server was at the limits of its hardware.
+
+To increase the number of allowed database connections, we had to upgrade to a bigger database. Fortunately, Heroku's Postgres tools make it simple to create a bigger database that follows the existing database, and then turn off replication and switch to using that bigger database as the new main database. Yesterday, I took down the API, created a new follower database that was able to support more connections, and then failed over to use it as the primary database. This resulted in roughly 53 minutes of downtime on July 15.
+
+Unfortunately, replication to the new, bigger database was only partially complete when I manually failed over to that database. The automated process that synchronizes the main RubyGems.org database to the API database wasn't able to fill in all of the missing data due to the way replication had copied only part of the information about some gems.
+
+Today, while investigating reports of failures during `bundle install`, we discovered the missing database data, and took down the API entirely to force everyone to use the accurate (but slower) full gem index. To repair the missing data, we restored a database backup from yesterday, and then synchronized the API database with the main RubyGems.org database to catch up on new gems. This caused roughly 3 hours and 16 minutes of downtime on July 16.
+
+Since the API was already down, we took the opportunity to improve the API database infrastructure. With the bigger database, we were able to remove our replica setup and instead just use a single database. We were also able to upgrade from Postgres 9.2.4 to 9.3.4, with performance enhancements and automatic failover. In the future, primary database failures should now be handled automatically.
+
+At this point, we have successfully upgraded to the latest version of Postgres, dramatically increased the hardware the database runs on, and increased the number of application servers from 15 to 20. We believe this fully armed and operational database will be faster and more reliable. Sorry for the downtime. Happy Bundling!

_posts/2014-08-14-bundler-may-install-gems-from-a-different-source-than-expected-cve-2013-0334.html.markdown

@@ -0,0 +1,58 @@
+---
+title: Bundler may install gems from a different source than expected (CVE-2013-0334)
+layout: post
+date: 2014-08-14 01:22 UTC
+author: André Arko
+---
+
+**Versions Affected**: All versions < 1.7.0  
+**Not Affected**: Any Gemfile with one or zero sources
+
+**Fixed Versions**: 1.7.0  
+**Releases**: 1.7.0
+
+Bundler 1.7 is a security-only release to address CVE-2013-0334, a vulnerability where a gem might be installed from an unintended source server, particularly while using both rubygems.org and gems.github.com.
+
+
+### Impact
+
+Any Gemfile with multiple top-level `source` lines cannot reliably control the gem server that a particular gem is fetched from. As a result, Bundler might install the wrong gem if more than one source provides a gem with the same name.
+
+This is especially possible in the case of Github's legacy gem server, hosted at gems.github.com. An attacker might create a malicious gem on RubyGems.org with the same name as a commonly-used Github gem. From that point forward, running `bundle install` might result in the malicious gem being used instead of the expected gem.
+
+To mitigate this, the Bundler and RubyGems.org teams worked together to copy almost every gem hosted on gems.github.com to rubygems.org, reducing the number of gems that can be used for such an attack.
+
+
+### Resolution
+
+To resolve this issue, upgrade to Bundler 1.7 by running `gem install bundler`. The next time you run `bundle install` for any Gemfile that contains multiple sources, each gem available from multiple sources will print a warning.
+
+It is recommended to use a source block to contain all gems intended to be installed from rubygems.org. An example of a vulnerable file would be:
+
+```
+source 'https://rubygems.org'
+
+gem 'rails'
+```
+
+The fix would be to move all gems into a source block for rubygems.org:
+
+```
+source 'https://rubygems.org' do
+  gem 'rails'
+end
+```
+
+For detailed information about the changes to how sources are handled in Bundler version 1.7, see the [release announcement](http://bundler.io/v1.7/whats_new.html).
+
+
+### Workarounds
+
+If you are unable to upgrade to Bundler 1.7, it is possible to work around the issue by removing all but one `source` line from your Gemfile. Gems from other sources must be installed via the `:git` option, which is not susceptible to this issue, or unpacked into the application repository and used via the `:path`option.
+
+Unfortunately, backporting a fix for this issue proved impractical, as previous versions of Bundler lacked the ability to distinguish between gem servers.
+
+
+### Credits
+
+Thanks to Andreas Loupasakis and Fotos Georgiadis for reporting this issue, James Tucker, Tony Arcieri, Eric Hodel, Michael Koziarski, and Kurt Seifried for assistance with the eventual solution, and David Radcliffe for importing legacy Github gems into RubyGems.org.

_posts/2014-08-15-gem-not-found-error-on-1-7-0.html.markdown

@@ -0,0 +1,9 @@
+---
+title: Gem not found error on 1.7.0
+layout: post
+date: 2014-08-15 17:02 UTC
+author: André Arko
+---
+After the release of Bundler 1.7.0 yesterday, we discovered a bug that can cause Bundler to report that a gem was not found, even though that gem is available from one of the relevant sources. We're understand the problem, and we're working on a fix as fast as we can. In the meantime, it's possible to work completely around the problem by adding the `--full-index` option when you run `bundle install`. I fully recognize that it sucks to have a regression in a security update, and I'm sorry that this happened. I can't guarantee something like this well never happen again, but we're adding tests to prevent this particular bug from recurring.
+
+Sorry it's broken; we're working on fixing it. In the meantime, please work around the issue with `bundle install --full-index`.

_posts/2015-03-19-announcing-ruby-together.html.markdown

@@ -0,0 +1,25 @@
+---
+title: Announcing Ruby Together
+layout: post
+date: 2015-03-19 02:56 UTC
+---
+
+All of the infrastructure used by Ruby developers today, including [Bundler][bundler], [RubyGems][rubygems], and [RubyGems.org](https://rubygems.org/) is maintained and developed by volunteers.  While it's good that no one company controls resources shared by the community, it's terrible that the only people who work on our shared infrastructure are doing so for free and in their spare time.
+
+[Ruby Together][rubytogether] was founded so the community can cooperate to solve that problem. It will fund on-call rotations, maintenance work, and improvements to the [shared, public infrastructure][projects] used by the entire community.
+
+We'll also provide [benefits just for members][benefits]. To begin with, opportunities to connect and exchange knowledge, turning [RubyBench.org](https://rubybench.org) into a fully-fledged community performance benchmarking resource, and tracking and reporting on important deprecations and security issues for members.
+
+The community that has grown up around Ruby is amazing, and provides many fantastic (and fantastically useful) tools that any developer can use. Let's work together to make sure those tools (and the community) are the best that they can be, for everyone.
+
+If you or your company has benefited from the free and open-source tools available in Ruby, support those tools by becoming a member of Ruby Together. Membership dues directly fund work that benefits everyone using Ruby, and are usually tax-deductible. Both individual and corporate memberships are available. [Join us today][join]!
+
+<span style="font-size: 80%">This post was originally written for [Ruby Together][post].</span>
+
+[rubytogether]: https://rubytogether.org
+[bundler]: https://bundler.io
+[rubygems]: https://rubygems.org/pages/download
+[projects]: https://rubytogether.org/projects
+[benefits]: https://rubytogether.org/benefits
+[join]: https://rubytogether.org/join
+[post]: https://rubytogether.org/news/2015-03-17-announcing-ruby-together