Blogs

Version Control API is central to Drupal's migration from CVS to git. It's also the single thing that's taken up the most time in the work we've done to date, and there's still a fair bit left to do. But we're now at a point where we need to step back and take a high-level look at the direction it'll finally take, so I thought I'd use where we are as an opportunity to explain the goals and architecture of the module, both historically and looking to the future.

It's official - the Drupal Association has selected me to be the 'Git Migration Lead.' I'm tremendously excited, and can't wait to knuckle down and get this migration DONE. I'll be launching full-tilt into the list of issues that stand between us and git goodness, but before I do, I want to take a minute to clarify how I understand and will be approaching this position.

Last week, Matt Farina tossed me a question about the best approach to introspecting code in PHP, particularly in relation to whether or not the situation was a good candidate for using PHP's Reflection API. The original (now outdated) patch he gave me as an example had the following block of code in it:

I've used Reflection happily in the past. I've even advocated for it in situations where I later realized it was the totally wrong tool for the job. But more importantly, I'd accepted as 'common knowledge' that Reflection was slow. Dog-slow, even. But Matt's question was specific enough that it got me wondering just how big the gap ACTUALLY was between the code he'd shown me, and the Reflection-based equivalent. The results surprised me. To the point where I ended up writing a PHP microbenching framework, and digging in quite a bit deeper.

User Panels shoots pretty high: it aims to provide a consistent, easy platform for the handling of user-centric information display. It's not about new storage mechanisms or anything like that - just about marshaling all that user content together in a sane, easy-to-use way. I'm hoping that this blog post can be a semi-official shout-out to the drupal community - an RFC, I guess.

user_panels comes out of a basic observation about Drupal: virtually every Drupal site has a different conceptualization of who users are, what their role is within the site, how they should be interacting with one another, etc. This observation helps explain why it's been so difficult to settle the question of how 'users' ought to be handled - most folks, myself absolutely included, are coming from the perspective of a particular use case. Even with deliberate effort, it's been pretty tough to get into a genericized head-space with respect to users. There are, I think, a couple reasons for this.

I've gotten a lot of good feedback about our KDI proposal since I posted it up a couple weeks ago, although a fair bit has been through one-on-one conversations I've had with folks. Generally, the feedback has been great (in both the complimentary and constructive criticism senses), although the venue has been a little unfortunate - I'd rather it be in comments on the issue itself, because we could use the momentum. But as I've been reading the thoughts of those who have been intrepid enough to comment, I realized that I'd managed to write a very long proposal without actually providing any specific examples. In particular, it was the comments by and subsequent discussions with moshe and eaton that led me to this conclusion.