Rails is growing up, indeed. I’m hoping that last week’s security incident with Rails will bring a few needed changes to the Rails world, some of which I’ll detail here. Before I get started, though, rest assured that I’m a very happy Railser. Even before I was completely sold on Rails, I admired what it could do (back in the 0.10 days, even). Now that I have been completely sold on Rails (since 0.13), life just wouldn’t be as good without it. 1.1.6 is a long way from 0.13, though, and now is as good a time as any to make some changes. I hope these thoughts can be be conversation starters for the Rails core team and those interested in the continuing success of the Ruby on Rails framework.
As we learned last week, people can get a little cranky when the framework on which they depend undergoes changes that disrupts their schedules. I myself was frustrated that so little information was initially released that I had to stop what I was doing to diff the subversion branches so I could find out what the problem was. Obviously, change happens, and it’s definitely better to get bugs fixed than not, but there are some things that can be done to improve the Rails development process that should help Rails continue to grow and be the thriving environment we all want it to be. Here are my suggestions that will help people like me, who derive their livelihood from development with Rails, continue to be successful with Rails and continue to be able to recommend it to clients, bosses, and the like.
First, here are some things we need realize about where the Rails community is today, so that we can focus our energies on supporting that community.
1. There is a large and growing community of developers, projects, and businesses that are relying on this framework for their success. Gone are the days that we can just toss out a release and expect everyone to upgrade quickly (or even at all). The events of last week showed there is a significant number of people that either can not or will not upgrade at a moment’s notice, either because their operating environment is too restrictive to move quickly without sufficient justification, or because they have made decisions (for whatever reason) to stick with a particular version of Rails. These people, who are often the champions of Rails in their organizations or among their peers, need to be considered when issues arise with or changes or made to the Rails framework.
2. Quite a community of code has grown up around Rails. There are now more than 300 plugins listed in the plugin directory, a few of which are very widely used, such as Acts as Authenticated and Rails Engines. Regardless of whether the core team uses or even likes the popular add-ons to Rails, the fact is that they are here to stay, and many people depend on them. If these add-ons are going to be broken by a release, we ought to know that before the release happens and have a plan for dealing with that breakage.
Now that we have a couple of ideas about the environment in which we find ourselves, here are my suggestions on how we can best support the Rails community as Rails continues to grow.
1. Have a QA team. This could start as a team of one, but I do feel the QA team needs to include people who are not core contributors, for two reasons. First, it always makes sense to have someone besides the developer verifying changes that are being made to the code. Of course unit testing is great, but you also need a fresh pair of eyes to catch things like a missing set of parentheses in a regular expression. Second, we don’t want to take any of the core team away from their responsibilities of actually building the framework by having them dedicated to QA. Yes, the developers should be reviewing each others work, but we want them to primarily build, not inspect.
2. Have a test matrix. We saw the beginnings of this in #rails-security last week. Let’s continue that good start by making the test matrix a permanent thing, with continuous integration regularly checking changes against various environments. The deployment scenarios should definitely include the plumbing variations like Apache/Mongel, Lighttpd/FastCGI, etc. The matrix should also include commonly-encountered environments, like applications dependent on the most popular plugins and Rails Engines.
3. Follow development best practices. As I mentioned, I was frustrated by having to resort to diff to get even a hint as to the nature of the security hole, but that frustration was compounded when I saw in that diff that additional features had been added to a bug fix release. I’m a big fan of the filter_logged_params plugin, and I’m glad it’s now in core, but a bug fix release is not the time to add it to core. If you are going to make a critical bug fix release and then urge people to immediately install it, the changes in the should be as minimal as possible. No new functionality should be added.
4. Improve the bug/patch submission process. I hesitated to add this item to the list, since I’m not sure I have a good recommendation, but the patch submission / bug reporting process needs some help. Patches languish far too long in Trac, frustrating those who submit them, and the signal-to-noise ratio can be low, frustrating those who review them. Perhaps the new QA team can be the front line of people who review new Trac submissions, thus reducing the noise seen by the core and letting them more quickly get to and incorporate the quality tickets.
Again, let me say how much I enjoy using Rails and how much I appreciate the effort put in by all those who contribute code, documentation, support, etc. This is why I felt I had to write this, as the better Rails is, the happier I’ll be. If these suggestions are followed, I know we’ll be on the track to a more reliable and predictable development and release process for Rails, and that will only make life better for all of us who use it.
Recent Comments