Update: Drupal.org is going Git!

Drupal.org's use of CVS as a version control system has long been a thorn in the side of the project and its contributor community. As many newer (and sexier) version control systems have popped up over the years, most of us have switched to something else for our day-to-day work, and the only time we need to remember how to use CVS again is when we are interacting with Drupal.org. It's a pain even for the most "blue-blooded" among us, and for some, this is a blocker to contributing back altogether. Dries has even identified playing around with other version control systems in his 8 steps for Drupal 8, and Larry also identifies it as a requirement for Drupal to realize it's not an underground success anymore.

Naturally, this situation prompts the periodic raising of the (perfectly reasonable) question by someone every few weeks of, "Why the %&#! is Drupal still using CVS?!" At one point, we got sick of expending time, energy, and focus on this question constantly, and so wrote up Why is Drupal still using CVS and how can I help change that?.

Unfortunately, no "help" ever materialized from the repeated linking of people over there, so after an impromptu IRC discussion the other day prompted by serial trouble-maker walkah, a few of us decided to brainstorm a list of what exactly it would take to gain some momentum on this goal (hey, testbot has been down for a few days, so we needed something to do! :P).

We created the following wiki page to centralize information and discussion, and coordinate mobilization around this effort:

Action items for moving Drupal.org off of CVS

The page has been up for about four days, and has had some very interesting discussion so far (happily, almost entirely devoid of meaningless "+1"-style comments). We've also in the process managed to wrangle a pretty nice list of resources for other projects who might be considering a similar move (or at least that's the hope)!

Here's a very high-level summary of the discussion so far:

• Based on our project/community goals, as well as the effort required to get there, there is no point in moving to a better centralized version control system. Distributed version control seems to clearly be the way of the future for massive hubs of collaboration such as Drupal.org, and so we've eliminated Subversion as a contender. We also eliminated Mercurial, based on lack of community expertise.
• Of the people in our community who use distributed version control systems, the overwhelming majority use Git. And by pulling random project metrics, Git also seems to be far and away the project with the most thriving community and most momentum behind it.
• However, Bazaar has the support of the Drupal.org infrastructure team, since it is capable of functioning as both a centralized and decentralized version control system, making the mental shift easier.
• We're currently exploring what sort of Drupal.org-related action items exist, as well as what possibilities exist for moving off of project* module, should we decide to do that, just to get all possible cards on the table.

So if you have expertise in Git or Bzr (or preferably, both), knowledge of the various Drupal.org infrastructure/Project* module details, and/or can provide more details to flesh out the blanks in the wiki, please head over to Action items for moving Drupal.org off of CVS and pitch in!

(Note: Comments are off on this post, because you should be posting over there instead. :))

Earlier today, I asked the fine folks from the Chicago Technology Cooperative what the status is of GMap and Location in terms of a Drupal 6 port. I expected at best a brief reply, probably followed by a "buzz off." ;)

Instead, Brandon Bergren and Rebecca White decided to join #drupal-dojo and spoke at length about the current status of the modules, what's needed to get them stable, and what the roadmap to Drupal 6 is. And, most importantly, they also went into details about how we can help (coders and non-coders alike! :)).

A summary of the talk (as well as the full IRC log) are posted at groups.drupal.org at The State of Geospatial in Drupal. The general plan is to get stable releases of the 5.x modules out first, then do straight ports to Drupal 6, followed by new development.

Want to help speed things along? Here's a list of the places to jump in if getting these modules stable is an itch for you, too.

Earlier tonight, Jimmy Berry posted a plea for the Drupal community to clean up their messes in terms of testing. Since Jimmy did a whole bunch of the heavy lifting involved in getting the SimpleTest framework ready to commit to core, a major milestone in Drupal's development, we'd do well to listen to his words and his frustrations when he sees all of his hard work falling apart due to neglect.

SimpleTest has only been in core for a month now, and already we've managed to break more than half the tests. This is a big problem. :\

In order for our community to embrace testing, we're required to bring several hundred people who've never written a test before in their lives (and might not even have heard of automated testing until heard some Drupal people talking about it) up to speed on what testing is, why it's a good thing, and how to do it.

But every time there's a bug in the testing framework, and every time an existing core test fails to run, this serves to completely destroy developers' confidence. If we're lucky, these people will go work on other things for a little while, and then check back periodically to see if things have been sorted things out yet. If we're unlucky, they start to develop animosity and resentment about the very idea of testing, and then start to distance themselves from doing development and encourage others to as well. Either way, the end result is stalling development on D7, and fewer people to spread the work around of writing further tests.

So how can someone concerned about the state of D7 development help?

Still stuck... er, I mean... visiting ;) Boston after Drupalcon, thanks to a lovely winter storm in Canada that refuses to go away. Karen Stevenson was nice enough to put me up in her hotel room for a night, so I wanted to pay her back by making this important issue my "itch of the week": we need to figure out a data model in order to move CCK fields in core efforts forward. See Karen's Field Structure thread for more details.

Currently, regular old single-value fields (like "first name") are easy. Just cram 'em in the content type table. But when you start moving into more advanced areas like shared fields (such as a "picture" field that's attached to both "book" and "video game" content types), or multiple-value fields (such as a group of checkboxes for "interests"), those currently get split off into their own tables in order to normalize things. Moving fields to and from multiple value and shared has always been a harrowing process, involving table structure manipulation and data migration. However, with the abstraction brought on by the new Schema API in core, this suddenly became a lot tougher.

A couple of options have been proposed, which include a de-normalized schema per content type (leading to a bunch of NULL values for multivalue fields and data duplication for shared fields), and a "each field in its own table" approach, which involves many (sometimes MANY many) joins, which can kill performance on a large site.

So, calling all database schema experts, SQL gurus, performance nuts, etc. We need your help. We need to make sure we're not missing any obvious options that would make this work more slickly, and we also need some help benchmarking to determine what the best option is going to ultimately be. Please head over to http://groups.drupal.org/node/9297 and post your thoughts!

This week's itch is another usability itch: adding example text to all textfields in core. There's work there in process to do stuff like emulate the Yahoo! registration form, where a faded-out example value is placed in initially, and disappears when the box gets focus:

On browsers that lack JS support, the example text will just be displayed next to the box.

How does this work?

I noted in my Drupal 7.x Personal Battleplan that I was going to focus on Usability and QA stuff this go around. So I've started a new segment called "itch of the week" to keep track of the efforts I'm working on to that effect. It'll be interesting (well... to me and probably no one else :P) to see if I can keep up with these weekly or not. ;)

Anyway. The first itch goes to.... permission descriptions!

This is a patch that was originally written by kkaefer way back in fall of 2005. It came back on my radar when I was observing Marci working with Drupal on her blog and struggling to figure out what the various options meant. It further came back on my radar when I heard a support request come in from a client about why their editor could see private site content intended only for administrators. Permissions are sometimes poorly named (I've come across some doozies in contrib :P) or have other implications that are not immediately obvious, such as roles with "administer nodes" permission bypassing any access control on content. This patch attempts to make these more obvious to folks.

Anyway, if this sounds like something that's interesting to you, please help review the patch, and we'll see if we can get it into Drupal 7.x. :)