Drupal commit history absolute
We opened the Drupal 7 development branch in February 2008, and released Drupal 7.0 in January 2011. This graph shows the stacked commit history from beginning to end. I appointed Angie as my Drupal 7 co-maintainer in August 2008 after having been the sole committer for 7 months. The peak around August 2009 (the highest peak) was the first attempted Drupal 7 code freeze. The momentum steadily built up towards the initial code freeze date. Interestingly, we remained most productive during the extended code freeze period ... more code freezes are better than one code freeze? ;-)
Drupal commit history relative
I averaged at 3.6 commits per day, whereas Angie's average is 2.6 commits per day (including weekends and holidays).


Nick (not verified):

You guys both rule. Thanks to you both (and everyone who was responsible for said patches!) for all the time you sacrificed for the good of Drupal!

catch (not verified):

The 'code slush' was indeed a very productive period, I think partly because people were sensitive that time was running out, partly because the slightly reduced scope of what could go in gave that period a lot of focus, while still having enough flexibility that it didn't only feel like slog (which much of the RC period did since we built up such a massive backlog of critical issues).

I would really like us to try opening up Drupal 8 development with a code slush, as opposed to an immediate thaw.

We traditionally have a short-ish, hot summer, followed by a very long winter than begins temperate, and gradually gets harsher and harsher, then it's straight back to tropical temperatures again.

This would be a proper thaw ('code spring'?), where we focus on much the same things as the code slush:

  • Bug fixes, many of which would be straight backports to Drupal 7;
  • Tests, like the 7-7 and 7-8 upgrade paths, refactoring of existing tests and improving simpletest performance;
  • Smaller performance fixes;
  • API cleanup and additions;
  • Potentially things like profile module refactoring which were clearly left over from Drupal 7, and have limited effect on breaking backwards compatibility;
  • Could also still have some exceptions - i.e. adding an exportables.inc to core would be a good enabler for future patches, without immediately needing to rewrite large areas of core to support it.

Another thing that helped focus efforts during the code slush was the 'unstable' releases, it helped to digest where and how API changes were being made, and it gave contrib authors better anchor points to develop against (although I'm not sure how much they got used in practice), nothing would stop us doing those semi-regularly throughout the cycle.


Interesting thoughts. In a way, this might be what happens naturally -- at least partially.

  1. Looking at the commit history graphs above, we usually are of for a "slow start". Developers get more motivated to contribute as a (potential) release date gets closer.
  2. When we started the Drupal 7 branch, one of the things we focused on early on was testing, which led to the inclusion of a test framework into Drupal 7.
  3. A lot of the big changes in Drupal 7 required significant planning, often including code sprints: many of the usability improvements, the new database abstraction layer, fields API, etc. They don't tend to happen early on in the release cycle as we need to do a lot of 'forming' and 'molding'.
  4. I also remember backporting a lot of bugfixes early on in the Drupal 7 release cycle. It is the primary reason why I haven't opened the Drupal 8 branch yet.
David Thorne (not verified):

The stats are interesting thanks for providing them. It's great to see what percentage other people commited to core - proof of the community nature of Drupal in action. Thanks to all the people who provided patches, and thanks to Angie and Dries for taking the time to apply them.

What will be particularly interesting is to see how this changes with regards D8 once the git mentality of commit more often has "sunk in". I realise the stats won't necessarily be true reflection of total commits any longer and it's dependant on what the project admins/D8 co maintainer accepts as pull requests.

Keep up the good work.

Jeff Eaton (not verified):

More metrics! More metrics! You realize, of course, that posting this kind of data only makes people hungry for more. ;-)

I'd be really interested in the correlation between commits, and issue queue activity. I know that some of the "lull" periods in commits were also times when really complex, thorny issues were being hammered out in the queue. Understanding the ebb and flow of that activity would be very interesting.


Metrics are important, because they help us look back and reflect on the Drupal 7 development process. I'll organize a retrospective discussion soon -- possibly later today. Data helps with such a retrospective.

Larry Garfield (not verified):

One thing to note that is not reflected here is "herding time", working with other developers before committing, coordinating people, talking through ideas, etc. Angie did an enormous amount of that, which is not reflected in these graphs. I really think Angie was the most active maintainer we've ever had, including Dries.

Just like code commit credits, stats like these tell only a tiny sliver of the overall picture. To some extent I think they're almost dangerously misleading.


Good point. Co-maintainers obviously do a lot more than just committing patches; including planning, herding contributors, public speaking, press interviews, listening to end-users, etc.

I'll be the first to agree that Angie did more "contributor herding" than I did, and that that isn't reflected in these statistics. If we created a graph of the "number of words published on drupal.org", I'm sure she'd be far ahead of me. :-)

I consciously try to adapt myself to my co-maintainer(s) so they can do what they do best. Angie is an expert herder of contributors, and passionate about it too, so I had to do less of it. I believe I did more herding in previous release cycles with my previous co-maintainers.

In general, I'd say that Angie was more inward focused, while I was more outward focused during the Drupal 7 development cycle. I did an insane amount of traveling to get people excited about Drupal 7 (public speaking), to listen to Drupal users and to participate in code sprints. I flew over 300,000 km (190,000 miles) in 2010 alone. While Angie did a fair amount of that, my guess is that I was more outward facing than she was. I think we complemented each other well in that regard.

As Larry wrote, the commit history provides an incomplete representation of what it means to be a Drupal core co-maintainer. I didn't mean to provide a complete picture. My goal was just to provide insight into how the development cycle evolved, hoping that we could learn from it in preparation of the Drupal 8 development cycle. I don't want to paint a misleading picture either; it goes without saying that Angie did an incredible job. I couldn't have been happier with her work as a co-maintainer.

Thanks for pointing this out, Larry!