DrupalCon 2010 Core Dev Summit Highlights

The first-ever Core Developer Summit was held Saturday at DrupalCon 2010. OJC Technologies was there to advance the accessibility of Drupal. It was a great day meeting and strategizing with about 150 of the (hard-)core developers who have made Drupal great, including Drupal creator Dries and the amazing Angie.

Big Issues

The group wrestled with how we can continue to improve and evolve. It's hard to be "lean and mean" when the number of people involved is growing so fast. We're running 100,000+ websites and big sites like Whitehouse.gov and we have millions of annual downloads. How do we avoid becoming a victim of our own success?

Many of the discussions focused on:

• the growing size of the drupal community, complexity and codebase
• the community decision-making process
• examining some of the common problems that stymie progress in the issue queue
• cleaning up core APIs and making core more object oriented
• managing user interface/user experience design in an open source project

Proposed Features for Drupal 8+

Lots of smart people proposed some great steps they are ready to take to make Drupal better:

• automatic installation of core updates through the web -- there are technical and security issues for updating core this way but it is recognized that it's important
• block layouts should be context-sensitive -- basically this means bringing functionality equivalent to Context / Spaces into core
• automated testing must include Javascript / AJAX features -- the problem with our current SimpleTest framework is that nothing is testing our Javascript

Solving the Dev/Staging/Production Problem

My colleague Bryan Cribbs will be delighted to know that one of the biggest conversations was about solving the dev-to-production problem. The problem is that both the website content and its configuration are mixed in the database and in files on disk. Hence there is no easy way to promote new configuration from dev to staging to production or to merge configuration updates from multiple active developer environments together.

The author of the Features module, which is 1 year old this month, gave a talk about where Features has succeeded and failed. He feels that "Exportables" is the best part of the Features module, and that it's a good thing to encourage serialization of settings so they can be written to disk and managed and merged with revision control systems. The problem is that there is no good concept of "Importables", so it is still too hard to use and apply things that have been exported. Exportables also does not handle SQL joins well, and doesn't work well when one module does a "hook_form_alter" to add one new setting of its own onto another existing module's settings page.

The break-out discussion included some great brainstorming:

• Idea: Create a consistent "Settings API" in core, so that any settings can be Exportable and Importable.
• Idea: Create a "system settings log" to be able to replay or rollback setting changes.
• The "Day 0" importing is the easiest situation to solve, meaning a way to import a set of exported features on "day zero" when you first create a new Drupal site. For this situation, all we need is a way to package up a feature so it can become an "install profile", which we basically have already.
• The harder problems are how you apply features later into an existing site without ID collisions, how you re-apply features even if they have locally changed, how you merge different developers' versions of a feature (such as a View or CCK) if they've each changed different parts of the same thing.
• Idea: Use UUIDs rather than database IDs so there is never an ID collision.
• Idea: Put system settings into a SQLite database so it can live on disk and in SVN at all times.
• Idea: Even if it's not SQLite, maybe we should be writing a lot of the settings to files to disk in a format that revision control systems can use to sort out the conflicts and merge them.
• Question: Should we separate configuration from content? Or is that a horrible idea because we actually want *both* to be easily deployed between Dev/Staging/Production?
• For example, a magazine publishing site wants to work on a whole new issue of the magazine in Dev/Staging and get it perfect and then deploy it all at once to Production, and that might be a mix of content nodes, menus, views, image files on disk, etc.
• Hence the tools that we create to migrate configuration changes should also be things we can use to migrate content. And if that is the case, then there is no use in separating configuration from content anyway because we need to solve the problem for both.

It was a great day. We finally got to meet people in person who we have labored with online in the issue queue for so long.

Check out the online slides of all the presentations at http://sf2010.drupal.org/conference/core-developer-summit.