Jun 28 2018
Jun 28

Greetings, folks! As we head into feature freeze for Drupal 8.6 (the week of July 18), here's a run-down of the various initiatives, and a hit-list of what they're trying to accomplish in the next two weeks. Patch reviews, testing, design, docs, and many more skills are very welcomed!

A couple of caveats here:

1) This is my own personal best understanding of where this stuff is all at, based on reading issue comments, attending meetings, overhearing things from other people who attended meetings, catching the odd Slack snippet of conversation, carrier piegon, etc. And therefore may not be 100% accurate, or even 80% accurate — there's a lot going on! (please clarify in the comments if you see any errors/omissions)
2) Just because something is listed here, there is absolutely no guarantee that it gets reviewed + (truly) RTBCed + committed in time for feature freeze and makes it into 8.6. As you can see, there are lots of issues in the list below, and we're all doing our best to stay on top of them. Worst-case, there's always 8.7. :)
3) This post gets into nitty-gritty "technical audience" details; if you're interested in a more broad overview of initiatives and their aims for 8.6 and beyond, there's the strategic initiatives overview on Drupal.org. I was also recently on a Lullbabot podcast to that effect.

OK, here we go! These are listed in alphabetical order.

Admin UI & JavaScript Modernization

This initiative has some lofty goals indeed, to redesign Drupal's admin experience, and modernize the underlying JavaScript code in Drupal to meet modern standards/best practices. While there's a ton of work actively going on in these areas right now, most of the fruit won't bear until 8.7 or later. If you're planning/able to go, come join the sprint next week at Drupal Developer Days Lisbon!

For 8.6, one of the big accomplishments of this initiative was introducing Nightwatch.js testing framework to core, which allows us to test JavaScript code with (wait for it)... JavaScript (what a concept!). This will be critical in ensuring that the React-ified components work as expected, and our existing JavaScript-rich functionality continues to work solidly as we expand on dynamic functionality in the UI.

Here are the issues this team has surfaced as important for 8.6:

Make Nightwatch testing more generally useful

  • Add login/logout commands to nightwatch [#2973879]
  • Create nightwatch command to install modules [#2974619 ]

Fix long-standing issues in the JavaScript system

Seriously, check out the five-digit node IDs on these bad boys! :P

  • ajax.js insert command sometimes wraps content in a div, potentially producing invalid HTML and other bugs [#736066] - Fixed!
  • Provide a common API for displaying JavaScript messages [#77245]

Bring JS code up to modern standards

  • Use Prettier for formatting core JavaScript [#2978964]

API-First

This team's 8.6 goals are two-fold: 1) stabilizing and filling gaps in the existing REST API, and 2) attempting to add JSON API to core.

TONS of work has been going on in the JSON API contributed module queue to fix a number of outstanding issues to make it core-worthy. So even if this module doesn't make it in time for 8.6, the entire ecosystem will benefit throughout 8.6's lifecycle by using a much more robust and well-tested contributed module. Additionally, a long-standing gap of file upload support has been added. Huzzah!

For the remainder of 8.6, the team would like to focus on the following:

Unblockers to API-First in general

  • Add DateTimeNormalizer+TimestampNormalizer, deprecate TimestampItemNormalizer: @DataType-level normalizers are reusable by JSON API [#2926508]
  • @DataType=map cannot be normalized, affects @FieldType=link, @FieldType=map [#2895532]

Unblockers to REST

  • EntityResource should add _entity_access requirement to REST routes [#2869426]
  • PATCHing entities validates the entire entity, also unmodified fields, so unmodified fields can throw validation errors [#2821077]

Unblockers to JSON API

These are all issues in the JSON API contrib module, which help unblock "Add experimental JSON API module [#2843147]" for core.

UPDATE July 3, 2018: The known blockers are all out of the way, so now there's a proposed core patch to review in that issue! Git to it! :D (See what I did there? ;))

  • [PP-1] Work around core's ill-designed @FieldType-level TimestampItemNormalizer normalization until #2926508 lands [#2929932] - Fixed!
  • JSON API indicates it supports POST/PATCH/DELETE of config entity types, but that's impossible [#2887313] - Fixed!
  • [>=8.5] Remove JSON API's "file URL" field work-around now that Drupal core 8.5 fixed it [#2926463] - Fixed!
  • Needs Issue: Module name conflict between contrib/core (what happens when we bring a same-named contrib module to core that sites are actively using?)

Automatic Updates / Composer in Core

These two initiatives overlap in that we're aiming to build the automatic update functionality around improving core's underlying Composer support.

The Composer team has compiled an excellent plan of attack for how to provide Composer support without jeopardizing the site builder experience. Most of that work will take place in 8.7.

UPDATE July 3, 2018: The team has proposed some of the concrete tasks needed under here for possible inclusion in 8.6. Needs patches, which then need reviews. Let's git er done! (I'm so, soooo sorry. ;))

However, one of the pre-requisites for Composer to work well, is adding semantic versioning support for contrib. Support for this would also be tremendously helpful to contrib module authors and site builders, regardless if they use Composer to manage their dependencies or not.

Composer-ify Core!

  • Add composer build support to core [#2982674] (plan issue)
  • Add composer-ready kickstart component to Drupal core. [#2982680]
  • Add a composer scaffolding plugin to core [#2982684]
  • Add a composer core-strict plugin to core [#2983089]

Unblockers to semver for contrib

  • Core version key in module's .info.yml doesn't respect core semantic versioning [#2313917]
  • Module version dependency in .info.yml is ineffective for patch releases [#2641658]

Configuration Management 2.0

This team spent most of the 8.6 cycle forming, brainstorming a list of blockers to configuration awesomeness, and prioritizing those efforts. The hope is for a roadmap to get published after the sprint next week at Drupal Developer Days Lisbon.

One major win in 8.6 is the ability to Allow a site-specific profile to be installed from existing config, which is part of the aim to Allow a site to be installed from existing configuration (basically, moving the capabilities of the Config Installer module into core.)

Unblockers of install from existing configuration

  • Allow a site-specific profile to be installed from existing config [#2788777] - Fixed!
  • Install a site from config if the config directory is set in settings.php [#2980670]

Documentation

The Documentation initiative has a lot on the go right now, from designing a top-level landing page for the new docs system, to taking a holistic look at the existing docs and how to refactor the IA around them, and finally creating a repository around "quick start" guides. None of these have a particular deadline around 8.6, because they're happening independently of core.

On the core side, there's work being done on a new experimental module for overhauling the in-app help system and this work has an 8.6 deadline.

New topic-based core help system

  • Refactor using a plugin system [#2961552] - Fixed!
  • Add experimental module for Help Topics [#2920309]

Extended Security Support

For the plan around this initiative to happen, we need to make several adjustments to core's Update Status module, which currently makes several hard-coded assumptions about the last minor release of Drupal expiring immediately once a new minor release is available.

Update Status Improvements

  • If the next minor version of core has a security release, status still says "Security update required!" even if the site is on an equivalent, secure release already [#2804155]
  • Status report should indicate next minor release date (needs issue)
  • (other issues TBD)

Layout

The Layout team has been hard at work improving upon the experimental Layout Builder functionality that was added to 8.5. The main goal of the team for 8.6 is to gather real-world testing feedback from end users, which they are accomplishing by adding Layout Builder to a new branch of the Lightning distribution. Doing this has uncovered a few holes in the implementation relative to what's possible in contrib right now, and filling those gaps is the focus of the remaining 8.6 time for the team.

Layout Builder gaps

  • Allow the inline creation of non-reusable Custom Blocks in the layout builder [#2957425]
  • Allow Custom blocks to be set as non-reusable adding access restriction based on where it was used. [#2976334]
  • Add a validation constraint to check if an entity has a field [#2976356]
  • Determine if Layout Builder should replace entity_view_display for all Entity Types [#2936358]
  • No ability to control "extra fields" with Layout Builder [#2953656]

Integration with other subsysytems/modules

  • [PP-1] LayoutBuilderEntityViewDisplay::getRuntimeSections() does not delegate to plugins [#2976148]
  • Add EntityContextDefinition for the 80% use case [#2932462]
  • [meta] Decide how Layout Builder should function with Content Moderation and Workspaces modules [#2973382]
  • Layout Builder does not respect translations [#2946333]
  • Track Layout override revisions on entities which support revisioning [#2937199]

Media

Media has made tremendous strides in 8.6, including remote video support and a newly designed media library.

Next, we need to integrate that media library into the node form, and ideally allow people to add from there as well in a more streamlined fashion.

Blockers to media awesomeness

  • Create a field widget for the Media library module [#2962525]
  • View inside core modal doesn't refresh correctly when reopened [#2861860]
  • (needs issue) Mark Media Library as beta
  • [PP-1] Allow media to be uploaded with the Media Library field widget [#2938116]
  • Any AJAX call disregards machine name verification when AJAX is used and leads to a fatal error [#2557299]
  • Provide a media library display for "Remote video" [#2982279]

Migrate

The goal of this initiative for 8.6 is to stabilize the migration system which means marking the experimental Migrate Drupal + Migrate UI modules stable. This was also the goal for 8.5. What's making it tricky is multilingual migrations, which are themselves tricky because there are a multitude of ways one might have set up multilingual functionality prior to it being included in core in Drupal 8, which introduces lots of edge cases around making IDs line up and whatnot.

The team is taking a two-pronged approach here:

1) Attempt to close all of the remaining i18n-related issues.
2) Worst-case, split off multilingual migrations to an experimental module, so that the rest of the system that works for 80%+ of sites can be marked stable.

Make Migrate Stable

  • [policy, no patch] Mark Migrate Drupal as stable [#2905736]
  • [policy, no patch] Mark Migrate Drupal UI as stable [#2905491]
  • [META] Multilingual migrations meta issue [#2208401]
  • Experimental migrate_drupal_multilingual module [#2953360]

Out-of-the-Box

The Umami profile was committed (albeit marked hidden) in 8.5, and major efforts have been going on to remove all of the "beta blockers" preventing it from being visible in the UI. The last of these—Install profile in settings.php and mismatch check makes re-installs of Drupal hard [#2975328]—just landed earlier this week!

From here to 8.6, the team is working on stability and accessibility improvements.

Umami awesomesauceness

  • Un-hide Umami in 8.5 to vastly improve Drupal's evaluator experience [#2957464]
  • Umami missing some Media "plumbing" found in Standard profile [#2939594] - Fixed!
  • Improve Umami demo's support for managing field display settings [#2980029]
  • Improve Umami Demo's header layout and responsive behaviour [#2980528]

Workflow

Last, but certainly not least, is the Workflow initiative, which aims to add the Workspace contributed module to core in 8.6 to facilitate content staging and full-site previews. The module was already committed to 8.6 awhile back, but must be brought up to "beta" level stability to remain in the tagged + shipped release.

Because Workspaces can only stage content that's revisionable, there's also a parallel effort to add revision-ability to more types of data in Drupal core.

UPDATE July 3, 2018: There was a meeting between Product Managers + Framework Managers that arrived at a more fully flusehed-out list of beta blockers for Workspaces, which are now reflected here. If you see a place you can help, please jump in!

Blockers to Workspaces Stability

  • WI: Workspace module roadmap [#2732071]
  • Add workspace UI in top dialog [#2949991]
  • Remove the automatic entity update system [#2976035]
  • Provide the ability to wrap the entire page with a border when opening off-canvas in the top position [#2976385]
  • Refactor workspace content replication plugin system to three services [#2958752]
  • Prevent changes that would leak into the Live workspace [#2975334]
  • Content Moderation and Workspace don't work together [#2971699]
  • Add a ContentRepository config entity so we can store fully configured repository handlers, which can be reused for the upstream values of a workspace [#2931067]
  • Rename to "workspaces" [#2916780] - not a "beta blocker," but beta deadline.
  • Expose cacheability metadata in WorkspaceCacheContext [#2934354] - Fixed!

MOAR revisionable thingies

  • Convert taxonomy terms to be revisionable [#2880149]
  • Convert custom menu links to be revisionable [#2880152]
  • Convert comments to be revisionable [#2880154]

Anything else?

Whew! That's QUITE a lot. Are there any issues out there that we're missing that you feel are mission-critical to get into Drupal 8.6? Feel free to suggest them, with the caveat that the longer the list is, the more distributed the community's and core committers' focus is.

Thanks for reading!

Aug 31 2017
Aug 31

After consultation with the various initiative teams + core committers, we have created a DRAFT of proposed product goals for Drupal 8.5 (feature freeze: January 29, 2018) and Drupal 8.6+ (date TBD; ~late summer 2018).

The overall goals are divided into the following priorities:

  1. Migrate
  2. Media
  3. API-First
  4. Layouts
  5. Workflow
  6. Outside-In
  7. Out-of-the-Box
  8. Community Initiatives

Please let us know your thoughts at https://www.drupal.org/node/2905741 by September 6,
2017 so we can hit the ground running in DrupalCon Vienna!

Aug 25 2017
Aug 25

In order to respond to both site builder and developer feedback about core experimental modules in Drupal 8, the committer team is proposing the following changes starting with the Drupal 8.5.x branch (which is now open for development):

  1. Experimental modules that have alpha stability will only be committed to development branches of Drupal 8.
  2. If an experimental module has not achieved at least beta-level stability by the alpha1 release of the branch itself, its development will move to the next development branch and the module will not be included in the branch's alpha release. (Or, alternately, the module may be removed from core if there's no clear path to stability.)
  3. Once an experimental module reaches beta stability, we now require (a) upgrade paths, and (b) backwards compatibility (or a deprecated BC layer) for any API improvements.

For example, if an initiative team wanted to add a new experimental module to core for their desired feature, they could introduce a patch that met the requirements for an experimental module and it could be committed to 8.5.x as an alpha-stability experimental module. However, by 8.5.0-alpha1 (the week of January 17, 2018), either the module would need to be in "beta" level stability (which means its API and data model would be considered stable, with upgrade paths and API BC layers provided when needed), or it would be left in the 8.6.x branch, but removed from the 8.5.x branch before tagging the alpha. 8.5.0 would ship without this new functionality, but (if completed in time) it could be available in the 8.6.0 release.

These policy changes are intended to address a number of frustrations with the existing experimental module process and to better meet expectations for non-core site builders and developers.

For background on this decision or to provide your feedback, see the core policy issue that discusses this proposed change. The issue is open for community feedback until September 6, 2017. Thank you in advance!

Jul 27 2017
Jul 27

Starting in Drupal 8, we've added the notion of Experimental Modules, to help provide an early look at core features which are not yet complete. A major focus of Drupal 8.4.0 has been stabilizing these experimental modules, so that they can "graduate" to stable modules which can be installed in production and leveraged by other core and contrib modules.

Here's a document that outlays the current status of each experimental module, as well as their goals with respect to the forthcoming 8.4.0 alpha deadline (which is this coming Monday, July 31). If you're looking for a productive way to help your favourite initiative during 8.4.0's alpha/beta/RC phase, check it out!

Here's the TL;DR:

  • Content Moderation: Move from alpha to beta
  • Workflow: Move from alpha to beta
  • DateTime Range: Move to stable
  • Inline Form Errors: Move to stable
  • Layout Discovery: Move to stable
  • Media Entity: Move to stable (so contrib can rely on it), but hide module from UI (so end users don't accidentally turn this on solo, as it causes UX regressions)
  • Migrate / Migrate UI: Get as close to stable as possible.
  • Place Block: Hide module from UI (so end users don't turn it on), propose instead as patch to Block module for 8.5.0
  • Settings Tray: Move from alpha to beta
Apr 11 2017
Apr 11

In recent weeks, I've seen a whole lot of FUD regarding the Drupal Community Working Group, and what it is they do or don't do. While I no longer serve in the CWG (I stepped down from all "extra-curricular" Drupal activities back in 2015 to focus on my family), most of the portrayals I've read are misinformed at best and completely inaccurate at worst. So, as an ex-member, who was uninvolved in recent events and therefore can perhaps speak more freely(?), I’d like to try and clear up a few misconceptions I've seen.

Some have characterized the CWG as some nebulous dark secret court of frothing SJW activists, gleefully acting as judge/jury/executioner, deliberately seeking out “bad apples" in the community to oust, laughing malevolently all the way. This is patently false, and nothing could be further from the truth.

In reality, barring "flash point" incidents like the most recent one, it’s a pretty mundane gig. It mostly involves watching for something to be brought across your "desk" via an incident report, then trying your best as an unpaid volunteer—appointed based on your demonstrated ability to stay neutral and diplomatic in a crisis—to help empower people in the community to solve their own problems.

This takes different forms. A lot of the times it’s simply giving people a safe place to post concerns where they know they’ll be looked at seriously. The CWG provides someone to speak to who will genuinely listen to your concerns, and will give both parties a chance to speak and feel heard. If the situation escalates, the CWG will sometimes suggest neutral third-parties to help mediate, or in the “bigger” cases, get directly involved with mediation themselves. And while the CWG is empowered to oust people from the community in extreme circumstances, a) to-date, they have only done so once, following a harassment incident at DrupalCon, and b) barring "extreme" circumstances such as that, it is only done after a last, *last* resort. All of this is laid out in the Conflict Resolution Policy and Process: https://www.drupal.org/conflict-resolution

If an individual has multiple, *multiple* complaints against them, in many cases driving others to either leave the community entirely or dramatically reduce their involvement in the project, and if every other attempt to resolve the situation has failed, which includes private mediation, one-on-one mentoring, sterner warnings, etc. then as a last-ditch effort something like an Action Plan is developed. This is summarized as:

"The aim of an action plan is to find a path forward that avoids additional harm to the community. Drafting an action plan should help people recognise what triggers these incidents and help them learn to respond differently by using alternative approaches to problem-solving.

However, the action plan may also serve as a "final warning." If further complaints come to the CWG, further action may be necessary. As a group, our authority derives from Dries, and when necessary, we also consult Dries and involve him in the process."

The template includes a summary of complaints (all of which have been already vetted by the CWG for validity), the impact the person's actions have had on members of the community, and a clearly outlined set of steps to perform to prevent future complaints (e.g. if you're feeling frustrated, WALK AWAY instead of engaging in online battles in the heat of the moment). The intent is to wake the person up a bit, to help them understand that their actions — regardless of how justified they feel they are in having taken them — have consequences, often on people they care about, and to give them a clear path to re-engage with the community in a constructive and healthy way.

The CWG will bend over backwards to help people not get to that point, *especially* if they have an extensive contribution record. At a certain point though, if a “body trail” develops of people leaving the community because of an individual's conduct, it becomes something that needs to be addressed, especially if you sit on a governing body with the mandate to keep the community healthy. This is the situation that happened with chx, whose self-ban from the community was widely publicized, and which keeps getting brought up in the context of recent events as somehow related, which it is not.

Some people might respond to this with "Well, then contributors should just grow a thicker skin." That's certainly one approach. However, you lose a lot of great contributors that way (and indeed, we already have), as well as a lot of new blood into your project. I've previously documented my first 5 minutes in the Drupal community. Had I not been "contractually obligated" to remain because of Google Summer of Code, that likely would've been my last 5 minutes in the Drupal community, as well. And there are 1000s of other contributors out there like "past webchick." Food for thought.

So thanks, CWG, for doing your part of the thankless and difficult job that is ensuring that the Drupal community remains a respectful and collaborative place for all of us to do awesome things. <3

Apr 11 2017
Apr 11

In recent weeks, I've seen a whole lot of FUD regarding the Drupal Community Working Group, and what it is they do or don't do. While I no longer serve in the CWG (I stepped down from all "extra-curricular" Drupal activities back in 2015 to focus on my family), most of the portrayals I've read are misinformed at best and completely inaccurate at worst. So, as an ex-member, who was uninvolved in recent events and therefore can perhaps speak more freely(?), I’d like to try and clear up a few misconceptions I've seen.

Some have characterized the CWG as some nebulous dark secret court of frothing SJW activists, gleefully acting as judge/jury/executioner, deliberately seeking out “bad apples" in the community to oust, laughing malevolently all the way. This is patently false, and nothing could be further from the truth.

In reality, barring "flash point" incidents like the most recent one, it’s a pretty mundane gig. It mostly involves watching for something to be brought across your "desk" via an incident report, then trying your best as an unpaid volunteer—appointed based on your demonstrated ability to stay neutral and diplomatic in a crisis—to help empower people in the community to solve their own problems.

This takes different forms. A lot of the times it’s simply giving people a safe place to post concerns where they know they’ll be looked at seriously. The CWG provides someone to speak to who will genuinely listen to your concerns, and will give both parties a chance to speak and feel heard. If the situation escalates, the CWG will sometimes suggest neutral third-parties to help mediate, or in the “bigger” cases, get directly involved with mediation themselves. And while the CWG is empowered to oust people from the community in extreme circumstances, a) to-date, they have only done so once, following a harassment incident at DrupalCon, and b) barring "extreme" circumstances such as that, it is only done after a last, *last* resort. All of this is laid out in the Conflict Resolution Policy and Process: https://www.drupal.org/conflict-resolution

If an individual has multiple, *multiple* complaints against them, in many cases driving others to either leave the community entirely or dramatically reduce their involvement in the project, and if every other attempt to resolve the situation has failed, which includes private mediation, one-on-one mentoring, sterner warnings, etc. then as a last-ditch effort something like an Action Plan is developed. This is summarized as:

"The aim of an action plan is to find a path forward that avoids additional harm to the community. Drafting an action plan should help people recognise what triggers these incidents and help them learn to respond differently by using alternative approaches to problem-solving.

However, the action plan may also serve as a "final warning." If further complaints come to the CWG, further action may be necessary. As a group, our authority derives from Dries, and when necessary, we also consult Dries and involve him in the process."

The template includes a summary of complaints (all of which have been already vetted by the CWG for validity), the impact the person's actions have had on members of the community, and a clearly outlined set of steps to perform to prevent future complaints (e.g. if you're feeling frustrated, WALK AWAY instead of engaging in online battles in the heat of the moment). The intent is to wake the person up a bit, to help them understand that their actions — regardless of how justified they feel they are in having taken them — have consequences, often on people they care about, and to give them a clear path to re-engage with the community in a constructive and healthy way.

The CWG will bend over backwards to help people not get to that point, *especially* if they have an extensive contribution record. At a certain point though, if a “body trail” develops of people leaving the community because of an individual's conduct, it becomes something that needs to be addressed, especially if you sit on a governing body with the mandate to keep the community healthy. This is the situation that happened with chx, whose self-ban from the community was widely publicized, and which keeps getting brought up in the context of recent events as somehow related, which it is not.

Some people might respond to this with "Well, then contributors should just grow a thicker skin." That's certainly one approach. However, you lose a lot of great contributors that way (and indeed, we already have), as well as a lot of new blood into your project. I've previously documented my first 5 minutes in the Drupal community. Had I not been "contractually obligated" to remain because of Google Summer of Code, that likely would've been my last 5 minutes in the Drupal community, as well. And there are 1000s of other contributors out there like "past webchick." Food for thought.

So thanks, CWG, for doing your part of the thankless and difficult job that is ensuring that the Drupal community remains a respectful and collaborative place for all of us to do awesome things. <3

Jan 04 2016
Jan 04

Porting your modules/themes/distros to Drupal 8? Starting this week, Drupal 8 contrib office hours are kicking off! Come by IRC to get help with porting projects, or offer help to others porting their projects:

Hope to see you there! :D

Nov 09 2015
Nov 09

(Stretching the definition of "core" a bit here, but this is important to Drupal 8, so hopefully this is ok. :))

Now that Drupal 8.0.0 is nearing its final release, the next task in front of the Drupal community is porting ALL the contributed projects! Luckily, this effort is very much underway, but the faster the majority of big modules are at least usable (ideally with stable releases), the faster Drupal 8 adoption will take off.

After talking to numerous project maintainers, including those with multiple Drupal 8 core commits, it seems like many would find value in having dedicated times during which to collaborate with other people porting projects to D8, get questions answered, get advice on sticky problems, and figure out where best to help.

If you'd like to help mentor these sorts of office hours, please add your name to the issue summary at http://www.drupal.org/node/2612094 and fill in the Doodle.

Rock!

Nov 09 2015
Nov 09

(Stretching the definition of "core" a bit here, but this is important to Drupal 8, so hopefully this is ok. :))

Now that Drupal 8.0.0 is nearing its final release, the next task in front of the Drupal community is porting ALL the contributed projects! Luckily, this effort is very much underway, but the faster the majority of big modules are at least usable (ideally with stable releases), the faster Drupal 8 adoption will take off.

After talking to numerous project maintainers, including those with multiple Drupal 8 core commits, it seems like many would find value in having dedicated times during which to collaborate with other people porting projects to D8, get questions answered, get advice on sticky problems, and figure out where best to help.

If you'd like to help mentor these sorts of office hours, please add your name to the issue summary at http://www.drupal.org/node/2612094 and fill in the Doodle.

Rock!

Oct 09 2015
Oct 09

Now that Drupal 8 is in release candidate phase, the goal is to get out of release candidate phase and onto release as quickly as possible. That means we'll be locking down the patches committed to 8.0.x fairly significantly, so as not to potentially disrupt stability.

What patches can get committed now?

This is a complete list of the issues that are allowed in Drupal 8 before 8.0.0:

  • critical issues: Issues that are (legitimately ;)) marked critical are the first priority to resolve ASAP during release candidate. We can and will roll back any other types of patches if they introduce critical issues, or impact our ability to fix a critical issue. Note that we may choose to defer critical fixes to 8.0.x/8.1.x if the impact vs. disruption ratio risks postponing release.
  • rc eligible: This tag is for non-invasive patches which solely make coding standards, testing, and docs improvements. Anyone may add (or triage) this tag.
  • rc target: These are a handful of exceptions to the above; generally major issues with both a high impact and low disruption that would be much better/easier to get in before release than after. Only core committers should set this tag.

And... that's it! :) If you feel your non-critical, non-docs/coding standards/tests patch should be considered for an exception to be committed during RC use the rc target triage tag to alert core committers to it. They can then review and choose to switch to rc target or not. In order to aid committers in making that decision, a good issue summary containing rc target justification will really help. A good issue summary is of course also important on rc eligible issues.

Make sure to read Allowed changes during the Drupal 8 release cycle and in particular the section on release candidates for more detailed information.

How long does this "commit freeze" go on?

Until Drupal 8.0.0's release. That could be a minimum of 4 weeks (RCs are released every two weeks, and we'll need at least two of them [including a 3 week notice on release date] to tell if we're release-ready), or a maximum of $your_bet_here. ;)

Over at Release branches for core patch releases/release candidates we're discussing ways we can potentially commit RTBC patches during RC without disrupting our ability to ship (think feature branches 0.1). Thoughts over there would be welcome.

Sep 30 2015
Sep 30

Start: 

2015-10-01 (All day) America/New_York

Organizers: 

The next (and hopefully final!) beta release for Drupal 8 will be beta 16! (Read more about beta releases.) The beta is scheduled for Thursday, October 1, 2015. To ensure a reliable release window for the beta, there will be a Drupal 8 commit freeze from 00:00 to 23:30 UTC on September 30 (later on today).

Beta 16 will include a couple of important changes, including the removal of the ! placeholder from t(), and the moving of vendor code from /core/vendor into /vendor.

Sep 05 2015
Sep 05

Drupal 8 hit the single digits for critical issues this week, so we have officially started in on the RC1 Release Checklist! :D Two of the items on there are:

In an effort to get as much testing in front of RC1 as possible, today with the help of numerous awesome people such as hussainweb, DuaelFr, tarekdj, klausi, dawehner, Wim Leers, cilefen, and many more, we were able to get all of the external libraries in Drupal 8 updated! :D

While we have a green board as far as automated tests go, nevertheless these changes could use additional eyeballs, so please be on the lookout for any weirdness, esp. in front-end functionality, for which we lack automated test coverage.

Jul 09 2015
Jul 09

Pursuant to the discussion at [policy] Require PHP 5.5, the minimum PHP version of Drupal 8 has been raised to 5.5.9, and this change will be included in the next Drupal 8 beta (8.0.0-beta13).

(PHP 5.5.9 was chosen because it is also the same minimum version as Ubuntu's LTS, which in turn influenced Symfony 3.0, Travis CI, etc.)

This is a future-proofing move which buys us a few things:

  • Some nice language features and a built-in opcode cache.
  • Compatibility with the latest versions of various external dependencies, including Guzzle 6 and the upcoming Symfony 3.0
  • Better security for our end users, since PHP 5.4 will become end of life September 15, 2015 (most likely prior to Drupal 8's release).

We looked extensively into the adoption and hosting support of PHP 5.5 prior to making this move. While there is not widespread adoption of PHP 5.5 as of today, we nevertheless found that most hosts offer the option for PHP 5.5, due to PHP's security policy.

Jun 11 2015
Jun 11

DrupalCI is the next-generation version of our beloved testbot. The MVP ("minimum viable product") is coming soon (rolled out in parallel with the old testbot for awhile).

Here's a sneak peak at what it'll look like and some of its new capabilities: https://groups.drupal.org/node/471473

Jun 05 2015
Jun 05

TL;DR We need to ship D8. ;)

I was sent this question today from a co-worker:

"We always talk anecdotally about how Drupal adoption slows before a new release and then picks back up. Do we have any data to support that for Drupal 7 or Drupal 6? I’d love to know the impact of Drupal 8 as well – but not sure that’s possible. Any thoughts?"

This is a great question, but since email is where information goes to die ;), I figured I would copy my response into a blog post as well.

Show me the data!

Since D8 has been in development so long, we don't have enough data showing on https://www.drupal.org/project/usage/drupal anymore since it prunes it after 3 years. :(

Here's a graph I made from trawling through historical data on https://archive.org/web/ though (source):

This only goes back to June 2008 which is after D6 came out, so it's not ideal, but we can still glean some useful data out of it.

Drupal 6

Here is a screenshot of the data from just prior to Drupal 7's release in January 2011:

A graph showing a gradual slope from 0 installs to about 300K installs over 3 years.

  • In December 2008 there were 77K installs of D6 (compared to 0 in January since it wasn't out yet :)) (77K% increase). This is when D7 was in active development.
  • At the end of 2009 there were 203K installs of D6 (163% increase). This was when D7 was in feature freeze.
  • At the end of 2010 there were 323K installs of D6 (59% increase). This was when D7 was just about to ship.
  • At the end of 2011 there were 292K installs of D6 (9% decrease). This is when D7 had been out for about a year and several key contributed modules were ported.
  • D6 usage has been declining ever since, and is currently at about 135K installs.

Drupal 7

Here is the data from 2011 to today:

A graph showing a much steeper upward slope, from a few thousand to nearly 1M sites.

  • At the end of 2010 there were 6.5K installs of D7. This is when D7 was just about to be released.
  • At the end of 2011 there were 230K installs of D7 (3438% increase). This is when D7 had been out for about a year and several key contributed modules were ported, and D8 was just beginning development (was mostly D7 bug fixes at this point). Of note, D7 usage eclipsed D6 usage just a few months later (Feb 2012).
  • At the end of 2012 there were 522K D7 installs (127% increase). This is when D8 was nearly done with feature development.
  • At the end of 2013 there were 728K D7 installs (39% increase). This is after D8 was in code freeze.
  • At the end of 2014 there were 869K (19% increase). This is when D8 was in beta.
  • As of last week (mid-2015) there were 984K installs (13% increase). D8 is currently still in beta, with ~25 critical issues remaining before release candidates.

Patterns

There are a few patterns we can discern from this data:

  • There is an enormous uptick in Drupal usage every new major release (though it's delayed until it reaches a "stable" state, i.e. after enough contributed modules are ported).
  • After that initial year or two of exponential growth, it slows down a lot.
  • The closer the next version is to being released, the slower the growth is of the current version. Generally, this is because people will postpone projects and/or use non-Drupal solutions to avoid incurring a major version upgrade.
  • Usage of the older stable version starts to decline after the newer major version reaches the "stable" state.

Why Drupal 8 will make this more betterer

There are a few enormous shifts coming with D8 that should change these patterns significantly:

  • Drupal 8 is much more fully-featured out of the box than any of its predecessors, so for many sites there is no need to wait on any contributed modules to begin building. Therefore we reach "stable" state (for sites that can do what they need to with just core) at Day 0, not 6-12 months later.
  • A number of key contributed modules that delayed porting of other key contributed modules in D6/D7 (Views, Entity Reference, Date, etc.) were moved into core in D8. So they're available right now—even before release—to build on. And indeed we're seeing other big ecosystem modules (Commerce, Rules, etc.) porting now, while D8 is still in development.
  • D8 will end the 3-4 year "big bang" release cycle. Instead, we'll be doing "small bang" releases every 6 months with non-backwards compatibility breaking feature/API improvements. That means we should hopefully stave off adoption decline much longer, and possibly even sustain the "hyper adoption" rate for much longer.
  • We will still eventually have a D9 "big bang" release (3-4 years from now) with backwards compatibility breaks, but only after it's amassed enough awesome functionality that couldn't be otherwise backported to D8. This will provide us with another "epochal" marketing event that D8 is giving us today (well, soon) in order to drive adoption even further.

Sorry, that was probably Way Too Much Information™ but hey, the more you know. ;)

Tags: drupaldrupal 8acquia
Jun 05 2015
Jun 05

TL;DR We need to ship D8. ;)

I was sent this question today from a co-worker:

"We always talk anecdotally about how Drupal adoption slows before a new release and then picks back up. Do we have any data to support that for Drupal 7 or Drupal 6? I’d love to know the impact of Drupal 8 as well – but not sure that’s possible. Any thoughts?"

This is a great question, but since email is where information goes to die ;), I figured I would copy my response into a blog post as well.

Show me the data!

Since D8 has been in development so long, we don't have enough data showing on https://www.drupal.org/project/usage/drupal anymore since it prunes it after 3 years. :(

Here's a graph I made from trawling through historical data on https://archive.org/web/ though (source):

This only goes back to June 2008 which is after D6 came out, so it's not ideal, but we can still glean some useful data out of it.

Drupal 6

Here is a screenshot of the data from just prior to Drupal 7's release in January 2011:

A graph showing a gradual slope from 0 installs to about 300K installs over 3 years.

  • In December 2008 there were 77K installs of D6 (compared to 0 in January since it wasn't out yet :)) (77K% increase). This is when D7 was in active development.
  • At the end of 2009 there were 203K installs of D6 (163% increase). This was when D7 was in feature freeze.
  • At the end of 2010 there were 323K installs of D6 (59% increase). This was when D7 was just about to ship.
  • At the end of 2011 there were 292K installs of D6 (9% decrease). This is when D7 had been out for about a year and several key contributed modules were ported.
  • D6 usage has been declining ever since, and is currently at about 135K installs.

Drupal 7

Here is the data from 2011 to today:

A graph showing a much steeper upward slope, from a few thousand to nearly 1M sites.

  • At the end of 2010 there were 6.5K installs of D7. This is when D7 was just about to be released.
  • At the end of 2011 there were 230K installs of D7 (3438% increase). This is when D7 had been out for about a year and several key contributed modules were ported, and D8 was just beginning development (was mostly D7 bug fixes at this point). Of note, D7 usage eclipsed D6 usage just a few months later (Feb 2012).
  • At the end of 2012 there were 522K D7 installs (127% increase). This is when D8 was nearly done with feature development.
  • At the end of 2013 there were 728K D7 installs (39% increase). This is after D8 was in code freeze.
  • At the end of 2014 there were 869K (19% increase). This is when D8 was in beta.
  • As of last week (mid-2015) there were 984K installs (13% increase). D8 is currently still in beta, with ~25 critical issues remaining before release candidates.

Patterns

There are a few patterns we can discern from this data:

  • There is an enormous uptick in Drupal usage every new major release (though it's delayed until it reaches a "stable" state, i.e. after enough contributed modules are ported).
  • After that initial year or two of exponential growth, it slows down a lot.
  • The closer the next version is to being released, the slower the growth is of the current version. Generally, this is because people will postpone projects and/or use non-Drupal solutions to avoid incurring a major version upgrade.
  • Usage of the older stable version starts to decline after the newer major version reaches the "stable" state.

Why Drupal 8 will make this more betterer

There are a few enormous shifts coming with D8 that should change these patterns significantly:

  • Drupal 8 is much more fully-featured out of the box than any of its predecessors, so for many sites there is no need to wait on any contributed modules to begin building. Therefore we reach "stable" state (for sites that can do what they need to with just core) at Day 0, not 6-12 months later.
  • A number of key contributed modules that delayed porting of other key contributed modules in D6/D7 (Views, Entity Reference, Date, etc.) were moved into core in D8. So they're available right now—even before release—to build on. And indeed we're seeing other big ecosystem modules (Commerce, Rules, etc.) porting now, while D8 is still in development.
  • D8 will end the 3-4 year "big bang" release cycle. Instead, we'll be doing "small bang" releases every 6 months with non-backwards compatibility breaking feature/API improvements. That means we should hopefully stave off adoption decline much longer, and possibly even sustain the "hyper adoption" rate for much longer.
  • We will still eventually have a D9 "big bang" release (3-4 years from now) with backwards compatibility breaks, but only after it's amassed enough awesome functionality that couldn't be otherwise backported to D8. This will provide us with another "epochal" marketing event that D8 is giving us today (well, soon) in order to drive adoption even further.

Sorry, that was probably Way Too Much Information™ but hey, the more you know. ;)

Jun 03 2015
Jun 03

Drupal 8 is nearing release, and with all the big architectural changes it brings, we want to ensure D8 upholds the same level of security as our previous releases. That's where you come in!

The security team is using monies from the D8 Accelerate fund to pay for valid security issues found in Drupal 8, from now until August 31, 2015 (open to extension). This program is open for participation by anyone.

Read more details here: https://www.drupal.org/drupal8-security-bounty

May 18 2015
May 18

As mentioned during Dries's DrupalCon LA keynote, the Drupal Community Working Group is now accepting nominations for the Aaron Winborn Award, to honour Drupal community members who demonstrate personal integrity, kindness, and above-and-beyond commitment to the Drupal community.

Nominations are open until Monday 15 June 2015, and the selected recipient will receive a scholarship and stipend to attend DrupalCon with recognition during a plenary session at the event.

Submit your nominations here: https://www.drupal.org/aaron-winborn-award

Apr 02 2015
Apr 02
Wim Leers's picture
  • https://www.drupal.org/node/2296009: being worked on by fgm
  • https://www.drupal.org/node/2429617: rerolled, dpovshed is working on
    profiling the costly asset handling as uncovered in comment 36 of that issue.
  • For the meta issue https://www.drupal.org/node/2467071, we have the
    following people working on it:
  • No actual profiling of cold cache/routing performance yet because people
    were still arriving; but initial discussions already happened amongst yched,
    dawehner, Alex Pott, amateescu, znerol, Berdir, xjm and Wim Leers. We'll
    start diving into that deeply tomorrow.
Wim Leers's picture

Today, we really got up to speed!

On the page cache front

(i.e. for closing the https://www.drupal.org/node/2467071 meta issue.)

On fixing performance issues other than those related to the page cache

  • dpovshed has been profiling the asset handling since yesterday, and has made lots of progress:
  • fgm was ALL over all the class loading-related issues:
  • m1r1k got https://www.drupal.org/node/2458763 to a green patch, and he's quickly getting close to an RTBC!
  • likin is rerolling https://www.drupal.org/node/2368987, znerol and Wim Leers did benchmarking, it is almost RTBC! That will make Drupal 8's internal page cache ~20% faster!
  • Yesterday, plach, Fabianx, dawehner and Wim Leers discussed next steps, Fabianx already rolled an initial version. plach is pushing it further. The current numbers: table views with 50 fields are 55% faster. Fabianx and plach are sprinting along from home!

On finding more performance issues

  • dawehner, amateescu, berdir, yched, znerol, pwolanin and others did a profiling deep dive. The goal was to find performance areas outside of rendering performance (where we already know how to move forward). We specifically focused on routing and the access checking that happens as part of routing. We were unable to identify any significant parts that we can speed up significantly. After hours of analyzing, we concluded that the only way forward was to not look for low-hanging or even high-hanging fruit, but to just make many small incremental improvements.
  • See https://www.drupal.org/node/2470679#comment-9823490 for all relevant issues: for all of the things we have identified as being improvements or worthy of investigation, we've resurfaced existing issues, or opened new ones.
    Several "novice profiling" issues are there too, which should be a good fit for people new at profiling, but still have a nice potential :)
  • At the dinner table, Alex Pott made an excellent point: we can dump many more things into PHP. We already have a compiled container. There's no reason why we can't also do this for loading classes (class map, see above), routing information, asset library information, and even compile an entity type class with all its handler classes into a single PHP file.
    Food for thought for the next days.
Wim Leers's picture

Still steaming ahead. Progress on many, many fronts at once. 4 patches committed, 6 RTBC, and several more approaching RTBC.

On the page cache front

(i.e. for closing the https://www.drupal.org/node/2467071 meta issue.)

  • mr.baileys and jan.stoeckler got "max-age on HTML responses wrongly set to `max-age=0, private` instead of `max-age=N, public` (breaks reverse proxies and client-side caching)" (https://www.drupal.org/node/2467041) committed!
  • mr.baileys did the above as part of working on "Bubbling of elements' max-age to the page's headers and the page cache" (https://www.drupal.org/node/2352009), which was determined to be blocked on other work.
  • swentel and borisson_ fixed the test failures for "Search results should bubble rendered entity cache tags and set list cache tags" (https://www.drupal.org/node/2464409), it is now approaching RTBC
  • borisson_ and swentel got "Adding/updating interface translations should invalidate page & render caches" (https://www.drupal.org/node/2428837) to RTBC!
  • klausi & pwolanin discovered and fixed "REST responses should have proper cache tags" (https://www.drupal.org/node/2471473) in the same day!
  • GoZ got "File/Image field formatters don't add a cache tag for the file they display" (https://www.drupal.org/node/2388023) to RTBC!

On fixing performance issues other than those related to the page cache

On finding more performance issues

We didn't do further profiling today. dawehner opened https://www.drupal.org/node/2470926 and https://www.drupal.org/node/2471657 also based on yesterday's profiling. Both of those have already been picked up by a contributor at the sprint!

EDIT: I stupidly forgot penyaskito's issue. Ping me if I forgot to mention another issue or your name! So many things going on, that it's easy to miss something!

Wim Leers's picture

Still steaming ahead. Progress on many, many fronts at once. 5 patches committed, 5 RTBC, and several more approaching RTBC.

On the page cache front

(i.e. for closing the https://www.drupal.org/node/2467071 meta issue.)

Enormous progress here!

  • borisson_ continued pushing "Search results should bubble rendered entity cache tags and set list cache tags" (https://www.drupal.org/node/2464409), forward, it is now *this* close to RTBC!
  • GoZ got "File/Image field formatters don't add a cache tag for the file they display" (https://www.drupal.org/node/2388023) committed!
  • borisson_ and swentel got "Adding/updating interface translations should invalidate page & render caches" (https://www.drupal.org/node/2428837) back to RTBC, after it was pushed back by a core committer.
  • pwolanin and klausi discovered "404/403 responses for non-existing nodes are cached in Page Cache/reverse proxy, are not invalidated when the node is created" yesterday, I filed it today, and pwolanin got a patch going and committed today!
  • amateescu started working on "Non-declarative (configurable) routes must be able to associate cache tags (was: Views access plugins alter route's access requirements, altered routes must have associated cache tags)" (https://www.drupal.org/node/2464657) this morning, and already got it to RTBC!

So, in other words, almost all known remaining ways to break the page cache have already been fixed, or are RTBC!

On fixing performance issues other than those related to the page cache

On finding more performance issues

Wim Leers's picture

Still steaming ahead. Progress on many, many fronts at once. 4 patches committed, 1 RTBC, and several more approaching RTBC.

On the page cache front

(i.e. for closing the https://www.drupal.org/node/2467071 meta issue.)

  • borisson_ and swentel got "Adding/updating interface translations should invalidate page & render caches" (https://www.drupal.org/node/2428837) committed!
  • Arla pushed "Drupal 8 only allows one user every 6 hours to register when page caching is enabled — caused by entity UUID in form state" (https://www.drupal.org/node/2465053) forward, a very tricky issue, with a bug that was discovered thanks to page caching now being enabled by default.

Note: "Move internal page caching to a module to avoid relying on config get on runtime" (https://www.drupal.org/node/2368987) was committed (listed below), which made Drupal 8's page cache significantly faster! And "All stack middlewares are constructed at the same time even for cached pages" (https://www.drupal.org/node/2473113) has the potential to make it faster still!

On fixing performance issues other than those related to the page cache

On finding more performance issues

We didn't do further profiling today.

Wim Leers's picture

THIS IS NOW OUTDATED, SEE COMMENT BELOW!
Monday vs. Saturday.

Test site is a fresh install of D8, with one node that contains an image and 3 terms. PHP 5.5.11, OpCache on.

We test both out-of-the-box performance (the "noapcMON" prefix, which stands for "no APC classloader, Monday's HEAD) and the performance with the APC classloader manually enabled for Monday's HEAD, because that is now enabled by default (the "apcMON" prefix).

Everything is tested with authenticated user 2, unless otherwise specified. Whenever SmartCache is used, we use [#2429617-50] for Saturday, and [#2429617-44] for Monday.

Page cache (anon)

(ab -c 1 -n 1000 http://host/)

  • Monday: 8.2 ms/request, 122 requests/s
  • Saturday: 6.5 ms/request, 154 requests/s

21% faster.

First, Monday's HEAD versus Saturday's, out of the box

Front page Run #noapcMON_uid2_frontpageRun #SAT_uid2_frontpage Diff Diff% Number of Function Calls 50,401 42,805 -7,596 -15.1% Incl. Wall Time (microsec) 115,684 107,829 -7,855 -6.8% Incl. MemUse (bytes) 19,902,800 19,879,976 -22,824 -0.1% Incl. PeakMemUse (bytes) 20,059,608 20,037,960 -21,648 -0.1%
/node/1 Run #noapcMON_uid2_node1Run #SAT_uid2_node1 Diff Diff% Number of Function Calls 68,984 62,432 -6,552 -9.5% Incl. Wall Time (microsec) 152,125 141,233 -10,892 -7.2% Incl. MemUse (bytes) 22,170,216 22,102,152 -68,064 -0.3% Incl. PeakMemUse (bytes) 22,345,368 22,277,408 -67,960 -0.3%
Front page + SmartCache Run #noapcMON_uid2_frontpage_smartcacheRun #SAT_uid2_frontpage_smartcache Diff Diff% Number of Function Calls 24,166 20,547 -3,619 -15.0% Incl. Wall Time (microsec) 61,401 57,484 -3,917 -6.4% Incl. MemUse (bytes) 11,795,520 11,766,952 -28,568 -0.2% Incl. PeakMemUse (bytes) 11,847,136 11,819,488 -27,648 -0.2%
/node/1 + SmartCache Run #noapcMON_uid2_node1_smartcacheRun #SAT_uid2_node1_smartcache Diff Diff% Number of Function Calls 50,713 45,061 -5,652 -11.1% Incl. Wall Time (microsec) 112,181 106,017 -6,164 -5.5% Incl. MemUse (bytes) 17,929,200 17,906,960 -22,240 -0.1% Incl. PeakMemUse (bytes) 18,018,312 17,996,720 -21,592 -0.1%

Second, Monday's HEAD versus Saturday's, with the APC classloader manually enabled for Monday

Front page Run #apcMON_uid2_frontpageRun #SAT_uid2_frontpage Diff Diff% Number of Function Calls 41,837 42,805 968 2.3% Incl. Wall Time (microsec) 106,594 107,829 1,235 1.2% Incl. MemUse (bytes) 19,565,368 19,879,976 314,608 1.6% Incl. PeakMemUse (bytes) 19,721,856 20,037,960 316,104 1.6%
/node/1 Run #apcMON_uid2_node1Run #SAT_uid2_node1 Diff Diff% Number of Function Calls 61,364 62,432 1,068 1.7% Incl. Wall Time (microsec) 139,801 141,233 1,432 1.0% Incl. MemUse (bytes) 21,938,992 22,102,152 163,160 0.7% Incl. PeakMemUse (bytes) 22,114,760 22,277,408 162,648 0.7%
Front page + SmartCache Run #apcMON_uid2_frontpage_smartcacheRun #SAT_uid2_frontpage_smartcache Diff Diff% Number of Function Calls 19,784 20,547 763 3.9% Incl. Wall Time (microsec) 57,131 57,484 353 0.6% Incl. MemUse (bytes) 11,850,104 11,766,952 -83,152 -0.7% Incl. PeakMemUse (bytes) 11,901,624 11,819,488 -82,136 -0.7%
/node/1 + SmartCache Run #apcMON_uid2_node1_smartcacheRun #SAT_uid2_node1_smartcache Diff Diff% Number of Function Calls 44,275 45,061 786 1.8% Incl. Wall Time (microsec) 106,685 106,017 -668 -0.6% Incl. MemUse (bytes) 17,982,224 17,906,960 -75,264 -0.4% Incl. PeakMemUse (bytes) 18,071,824 17,996,720 -75,104 -0.4%
Fabianx's picture

We found 2 performance regressions that are not part of the above benchmarks:

With both applied we save:

-144 function calls
-0.5%

( @todo Add final benchmark numbers )

Also cold cache performance is much better with Yaml File Cache now:

Monday: 5.7-6.5 seconds
Saturday+Plus Some: 3.9 - 4.5 seconds

Hence saving on average 30% after a 'drush cr'.

Wim Leers's picture

The profiling I did above was flawed: I was selecting the fastest out of 10 runs, due to time constraints. That lead to unreliable numbers. Especially because it meant rendering each page (and the XHProf results page) in the browser.

I redid that, this time using benchmarking, which doesn't suffer from variability quite as much.

Before vs. After

  • Before = 700499c2598122c973909799e18c118661bd136e
  • After = 5f987ee0acfb7843c4050a2f7b8ff9da274945b3

Test site is a fresh install of D8, with one node that contains an image and 3 terms. PHP 5.5.11, OpCache on.

We test both out-of-the-box performance (before, which stands for "no APC classloader", which was the default before the sprint) and the performance with the APC classloader manually enabled for HEAD before the sprint, because that is now enabled by default (before-apc).

Everything is tested with authenticated user 2, unless otherwise specified.

Before each test, Apache is restarted. Benchmarked using ab -n 1000 -c 1 -C <sessioncookie> <URL>. If the standard deviation looks suspiciously high, thus pointing to other apps on my development laptop taking up too much CPU or I/O time, then I re-ran it. Usually it took 2 to 3 runs.

Percentage deltas in the conclusions are taken by looking at the mean, not the median, because the median does not have more granularity than the millisecond level. Comparing the differences in mean is acceptable here because the standard deviation is always low.

Observed performance

Page cache (anon)

(ab -c 1 -n 1000 http://host/)

before Requests per second:    117.77 [#/sec] (mean)
Time per request:       8.491 [ms] (mean)
Time per request:       8.491 [ms] (mean, across all concurrent requests)
Transfer rate:          1498.69 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     7    8   0.5      8      12
Waiting:        6    8   0.5      8      11
Total:          7    8   0.5      9      12

before-apc Requests per second:    121.77 [#/sec] (mean)
Time per request:       8.212 [ms] (mean)
Time per request:       8.212 [ms] (mean, across all concurrent requests)
Transfer rate:          1549.66 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     7    8   0.5      8      12
Waiting:        6    7   0.5      7      12
Total:          7    8   0.5      8      13

after Requests per second:    154.76 [#/sec] (mean)
Time per request:       6.462 [ms] (mean)
Time per request:       6.462 [ms] (mean, across all concurrent requests)
Transfer rate:          1969.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       1
Processing:     5    6   0.6      6      21
Waiting:        5    6   0.4      6       8
Total:          5    6   0.6      6      21

Conclusion 24% faster out of the box. 21% faster if you had manually enabled APC.

Front page (auth)

before Requests per second:    11.75 [#/sec] (mean)
Time per request:       85.076 [ms] (mean)
Time per request:       85.076 [ms] (mean, across all concurrent requests)
Transfer rate:          151.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    82   85   1.5     85      91
Waiting:       73   75   1.5     75      83
Total:         82   85   1.5     85      92

before-apc Requests per second:    12.30 [#/sec] (mean)
Time per request:       81.273 [ms] (mean)
Time per request:       81.273 [ms] (mean, across all concurrent requests)
Transfer rate:          158.91 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    78   81   1.3     81      89
Waiting:       69   72   1.3     72      80
Total:         79   81   1.3     81      89

after Requests per second:    12.66 [#/sec] (mean)
Time per request:       78.984 [ms] (mean)
Time per request:       78.984 [ms] (mean, across all concurrent requests)
Transfer rate:          163.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       1
Processing:    75   79   1.7     79      89
Waiting:       66   70   1.6     70      80
Total:         75   79   1.7     79      89

Conclusion

7% faster out of the box. 2.5% faster if you had manually enabled APC.

/node/1 (auth)

before Requests per second:    9.95 [#/sec] (mean)
Time per request:       100.480 [ms] (mean)
Time per request:       100.480 [ms] (mean, across all concurrent requests)
Transfer rate:          189.13 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    97  100   1.8    100     110
Waiting:       86   90   1.7     89      98
Total:         97  100   1.8    100     110

before-apc Requests per second:    10.28 [#/sec] (mean)
Time per request:       97.304 [ms] (mean)
Time per request:       97.304 [ms] (mean, across all concurrent requests)
Transfer rate:          195.51 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    91   97   3.6     97     152
Waiting:       83   86   3.4     86     138
Total:         91   97   3.6     97     153

after Requests per second:    10.63 [#/sec] (mean)
Time per request:       94.053 [ms] (mean)
Time per request:       94.053 [ms] (mean, across all concurrent requests)
Transfer rate:          202.65 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    89   94   1.9     94     120
Waiting:       79   84   1.8     84     111
Total:         90   94   1.9     94     120

Conclusion

6.4% faster out of the box. 3.3% faster if you had manually enabled APC.

Bootstrap/routing/route access checking performance

Here, we measure with the SmartCache patch applied, which reduces the time spent in rendering significantly, thus mostly leaving the bootstrap/routing/route access checking performance. before is omitted, only before-apc is tested, because we only care about actual performance gains in bootstrap/routing/route access checking, if any.

We use [#2429617-50] for before, and [#2429617-44] for after.

Front page + SmartCache (auth)

before-apc Requests per second:    22.63 [#/sec] (mean)
Time per request:       44.186 [ms] (mean)
Time per request:       44.186 [ms] (mean, across all concurrent requests)
Transfer rate:          292.29 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    41   44   1.1     44      57
Waiting:       37   39   1.1     38      51
Total:         41   44   1.1     44      57

after Requests per second:    22.60 [#/sec] (mean)
Time per request:       44.246 [ms] (mean)
Time per request:       44.246 [ms] (mean, across all concurrent requests)
Transfer rate:          291.78 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    41   44   1.1     44      50
Waiting:       36   39   1.0     39      45
Total:         41   44   1.1     44      50

Conclusion

Unchanged.

/node/1 + SmartCache (auth)

before-apc Requests per second:    13.70 [#/sec] (mean)
Time per request:       73.003 [ms] (mean)
Time per request:       73.003 [ms] (mean, across all concurrent requests)
Transfer rate:          260.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    68   73   1.4     72      81
Waiting:       62   65   1.4     64      73
Total:         68   73   1.4     73      81

after Requests per second:    13.77 [#/sec] (mean)
Time per request:       72.637 [ms] (mean)
Time per request:       72.637 [ms] (mean, across all concurrent requests)
Transfer rate:          262.30 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    70   72   1.3     72      80
Waiting:       62   64   1.3     64      72
Total:         70   73   1.3     72      80

Conclusion

Unchanged.

Cold cache performance

See Fabianx' comment above.

Mar 26 2015
Mar 26

Hopefully you've heard the news about the Drupal Association's new D8 Accelerate grants program, and the fundraising drive we have currently going on. If not, the gist is that the Drupal Association has created a central fund, managed by the Drupal core committers, to fund both "bottom-up" community grants for things like targeted sprints or "bug bounties," as well as "top-down" spending driven from the core committers on larger strategic initiatives that help accelerate Drupal 8's release. All D8 Accelerate grants that are provided are tracked centrally at https://assoc.drupal.org/d8accelerate/awarded, including what the money was used for, how much was spent, to whom it went, and a report from the grant recipient(s) that outlines the work that was accomplished.

However, it can be a little hard to parse from that format the larger meaning/context of this work, especially if you don't spend upwards of 30 hours per week in the core queue like most of these folks. :) As Chief Wearer of Many Hats™, I sit on both the Drupal Association board as well as the committee who manages these funds. This puts me in a good position to provide a bit of "behind the scenes" info on how the funding process works, as well as provide some of the larger story of how these funds are benefitting not only Drupal 8 core, but the larger Drupal ecosystem.

Drupal 8 Acceleration

Performance

A flamegraph of what functions take the longest on the user/password page in Drupal 8
Source: https://www.drupal.org/node/2370667

As noted in my post-DrupalCon Bogotá critical issue run-down, performance improvements are a large chunk of the work remaining in Drupal 8. We had deliberately postponed most of this work until post-beta to avoid premature optimization and to allow all the major architectural chunks to be in place. However, we definitely can't release Drupal 8 while it is much slower than Drupal 7.

The D8 Accelerate fund has been instrumental in not only helping to address critical performance regressions, but also in accelerating the development of Drupal 8's next-generation cache system.

Or, to sum it up in a cheesy catch-phrase:

For less than $10,000, we're making Drupal 8 twice as fast! :D

Win!

Unblocking the beta-to-beta upgrade path

The second large focus of D8 Accelerate grants has been around D8 upgrade path blockers. These are extremely strategic, because they unblock a beta-to-beta upgrade path between Drupal 8 releases, which is extremely important for early Drupal 8 adopters.

For example, one large chunk of work D8 Accelerate has funded is in making sure Entity Field API and Views work well together. This is critical for features such as Multilingual, so content shows up in the right languages when expected, and it's necessary to complete this work prior to providing an upgrade path since it would be horrendous to write hook_update_N() functions for some of the necessary changes.

We're also exploring other alternatives to provide a beta-to-beta upgrade path to early adopters sooner, which is viable now that the hardest data-model-changing issues are done.

Security

Drupal drop on a padlock
Source: http://www.codepositive.com/code-positive/about

Obviously, we do not want to release Drupal 8 with known security vulnerabilities, but neither do we want to release an "upgrade path beta" that we encourage early adopters to use with known security vulnerabilities. Hence, we are trying to get any critical security issues taken care of sooner than later.

For example, one chunk of work that D8 Accelerate is funding in this area is tightening security around Drupal 8 entity API. Numerous form validation functions in core contain entity-level validation, to the wild dismay of anyone who's ever tried to implement web services on top of Drupal. The reason that's bad is because if you attempt to save something using just the Entity API (as you will in a REST API scenario where there are no forms), you will end up skipping validation routines and could end up with invalid and/or insecure data entry.

Targeted Sprints to Crush Criticals

Menu link critical sprint at DrupalCamp New Jersey
Source: https://groups.drupal.org/node/456353

As demonstrated at the Ghent critical issue sprint last year, nothing is better for D8's velocity than getting a bunch of awesome contributors in the same place to pound on the critical queue together. D8 Accelerate funded a fantastic Menu link critical sprint at DrupalCamp New Jersey which, in addition to turning this area of criticals from "OMGWTFBBQ" to an actionable plan, resulted directly or indirectly in all of the related critical issues in this area being closed, within a couple of weeks after the sprint.

We aim to do more of these same types of targeted sprints throughout the year, the next one being the DrupalCI sprint in a couple of weeks. More on that in a sec.

Testbot modernization

Architectural diagram of new testbot
Source: https://www.previousnext.com.au/blog/architecting-drupalci-drupalcon-ams...

Our beloved Drupal.org testbot has been showing its age. https://qa.drupal.org/ is still on Drupal 6, and largely on life-support these days. Testbot doesn't support testing on multiple PHP versions and databases, both of which are Drupal.org (websites/infra) blockers to a Drupal 8 release.

The DrupalCI: Modernizing Testbot Initiative is being driven by numerous devops-inclined community members from around the world. It aims to rebuild testbot from a collection of Drupal modules to a more standard CI stack (using big fancy words like Jenkins and Docker and Puppet and Travis and Silex) that your average PHP/devops folk can both understand and help maintain.

There's been a lot of work on DrupalCI already, and the upcoming D8 Accelerate sprint on DrupalCI: Modernizing Testbot Initiative will bring all the various contributors together to form DrupalCI Voltron to get an MVP of all the various pieces working together. Actual deployment will happen some time later, and both the new and old testbot will run alongside each other for a good while so any kinks can be worked out while D8 development stays stable.

This particular improvement not only allows Drupal 8 to ship, it also will provide great new functionality to all projects on Drupal.org! The architecture allows for ample room for later expansion as well, so we could start doing things like automated code reviews, performance testing, front-end testing, etc.

People power!

Here are some of the awesome Drupal contributors who've benefited from these funds:

Not just code!

D8 Accelerate funds are being used not only to fund development work, but also to fund patch reviews as well as more "project management"-y tasks like "triaging" a set of issues to find the truly critical ones, research on different approaches, etc. Wherever possible, the core committers explicitly look for opportunities to fund two people, usually a developer and a patch reviewer, in order to maintain the sanctity of Drupal core's peer review process.

I think this is great, because it highlights that it's not just raw PHP that's going to get Drupal 8 out the door; it's a joint effort of many complementary skills coming together.

Show me the money!

Skeptical cat is fraught with skepticism
Source: https://blackincense.files.wordpress.com/2008/10/skeptical-cat-is-fraugh...

Why $250k to accelerate D8?

This is a very reasonable question to ask, particularly in light of the widely-cited statistic of 2,750+ contributors to Drupal 8, and various Drupal companies employing major contributors to Drupal core. Here are a few points:

  1. Drupal 8 will be a truly revolutionary release, not only by providing tons more useful functionality out of the box for site builders and content authors (WYSIWYG, mobile support, Views, configuration management, etc.), but by modernizing the underlying code base to address years of technical debt, and help "future-proof" Drupal for the next 10+ years. Unsurprisingly, this means that the total amount of work that has already gone into D8, and that remains needed to move D8 from a late beta to a release, is larger than it was for earlier versions of Drupal. Most technology maturations follow that pattern.

    Drupal 8's release also unlocks the move to a new release cycle that introduces backwards-compatible feature releases every 6 months. This allows us to "release early, release often," as opposed to "release every 4+ years, coupled with lots and lots of API breaks." ;)

  2. For these reasons, as well as many others, there's significant community benefit for 8.0.0 to be released as soon as possible, both so that sites can be built on it, and so that the 8.1.x branch can be opened for development for everyone with a feature idea itch to scratch. Additionally, many organizations and individuals who would benefit from D8 getting released sooner than later don't have the expertise or time to solve the remaining critical issues. These organizations/people might be willing to contribute money, but don't know who to best send it to or don't want to deal with the administration of contracting directly with individual core contributors. This fund is an opportunity for those organizations/people to make a difference without dealing with that administration.

    Make no mistake: Drupal 8 will get done, with or without this money. The goal of the fund is not about saying that our current awesome core contributor base is incapable of completing the work; it's only a recognition that funding work can make it happen faster.

  3. Why is this so? It's a common misconception that most core developers are paid for their work, either by Drupal companies who employ them, or by their customers. In reality, those directly financially compensated for their contributions to core (and especially to Drupal 8, which is not yet commercially viable for the masses) are a tiny fraction of the overall number of contributors.

    While there are numerous contributors who have already spent literally years contributing to core during their nights and weekends, and as a result have developed the kind of expertise needed to finish some of the remaining hard critical issues, relying on their ongoing availability of free time is not sustainable. These include contributors who work as freelance developers for clients, and it's certainly unfair to expect these people to turn down paid client work in order to have free time to work on core, or to quit being freelancers and become employees of forward-thinking Drupal companies who provide company time for core contribution. One of my favorite aspects of D8 Accelerate is that it is helping to "level the playing field" by making it possible for these people to have time to work on core regardless of their current employment situation.

    In short, don't confuse "has a job" with "is paid to work on Drupal core."

  4. It's also important to emphasize here that injecting funding into the "bug fix slog" phase of major Drupal releases, when all the fun stuff that tends to motivate volunteers is long exhausted, is nothing new. That should come as no surprise, given that there have always been companies with financial interests in having a given version of Drupal ready sooner. For example, in Drupal 6, Acquia funded release manager Gábor Hojtsy full-time to help get that release done. In Drupal 7, in addition to employing core contributors full-time, Examiner.com paid numerous "bug bounties" out to folks to help slay specific critical issues. The difference here is that the DA as a non-profit organization needs to be extremely transparent in anything it's doing with the community's money, so there is greater visibility on things this time around.

If you don't want to donate, that's totally okay. You'll still be able to use Drupal 8 all you want, for free, when it's ready. Donating to this fund is only an opportunity to help make that happen sooner, if that's sufficiently valuable to you.

For a lot more "deep thinking" around these topics, see:

Many thanks to effulgentsia for his extensive help on this part!

How do you decide on how money gets spent?

The core committers have a well-documented process that explains how we decide what to fund. The TL;DR version is we look at criteria like:

  • Is a proposal genuinely a release blocker to Drupal 8, or something that will otherwise directly lead to an accelerated Drupal 8 release? (That's a biggie.)
  • Is a proposal resolving a blocker to other work, especially other release blockers?
  • Is a proposal resolving an "ecosystem" blocker? (For example "D8 upgrade path" issues that block early D8 adoption, blockers to a major portion of contributed modules/themes porting)
  • Is this a place where we can inject funding to take an issue the "last 20%" and get it across the finish line quickly?
  • Is momentum in this area slow, making it unlikely to be fixed "organically" by D8 contributors?
  • Are the people working in this area not directly funded (by an employer or client) to fix it already?
  • Do we have some confidence that funding will lead to a successful outcome?

Proposals that answer "yes" to more of these questions than not are more likely to get funded. And the D8 Accelerate team is constantly on the lookout for things that meet this criteria and proactively reaching out to contributors to help get things started.

In short, we take our responsibility with the community's money very seriously, and have turned down multiple community proposals that were fantastic ideas, but did not fit this criteria. (Where appropriate, we refer folks over to the Community Cultivation Grants instead.)

Also please note that a previous restriction around people asking for funding for their own time has been lifted a month or so back (Thanks, DA!). So if you are a contributor who knows a lot about critical issue #12345, you can request a stipend (initially capped at $500 for five hours) to help push it forward.

If that sounds like you, or you have other creative ideas on how we can get Drupal 8 out faster, apply for a grant today!

Thank you for your support!

I wanted to take the opportunity to give a huge shout-out to the "anchor donors" of the D8 Accelerate campaign:

Thanks to their efforts, every dollar you contribute is already matched by the Drupal Association and these anchor donors, doubling your impact. If you'd like, you can make a donation to my fundraising drive (I've set a very ambitious goal of $20,000 since that's 8% of $250,000 — get it? ;)):

Fundraising Websites - Crowdrise

(Note: This is just the amount in my personal fundraiser; the overall fundraiser is at $135K and counting.)

...or, find your favourite Drupal person at https://www.crowdrise.com/d8accelerate/fundraiser and donate to theirs instead, or create your own! :)

Thanks as well to the folks who somehow stumbled across it and donated to my fundraiser already—Andreas Radloff, Douglas Reith, and Ian Dunn. I thought Ian's note was particularly awesome! :D

As a WordPress developer, I think we're all on the same side and wish you the best :)

And finally, thank YOU for any and all support you can provide that will help us make Drupal 8 the most successful release of Drupal yet! :D If you have any other questions, please feel free to ask!

Mar 26 2015
Mar 26

Hopefully you've heard the news about the Drupal Association's new D8 Accelerate grants program, and the fundraising drive we have currently going on. If not, the gist is that the Drupal Association has created a central fund, managed by the Drupal core committers, to fund both "bottom-up" community grants for things like targeted sprints or "bug bounties," as well as "top-down" spending driven from the core committers on larger strategic initiatives that help accelerate Drupal 8's release. All D8 Accelerate grants that are provided are tracked centrally at https://assoc.drupal.org/d8accelerate/awarded, including what the money was used for, how much was spent, to whom it went, and a report from the grant recipient(s) that outlines the work that was accomplished.

However, it can be a little hard to parse from that format the larger meaning/context of this work, especially if you don't spend upwards of 30 hours per week in the core queue like most of these folks. :) As Chief Wearer of Many Hats™, I sit on both the Drupal Association board as well as the committee who manages these funds. This puts me in a good position to provide a bit of "behind the scenes" info on how the funding process works, as well as provide some of the larger story of how these funds are benefitting not only Drupal 8 core, but the larger Drupal ecosystem.

Drupal 8 Acceleration

Performance

A flamegraph of what functions take the longest on the user/password page in Drupal 8
Source: https://www.drupal.org/node/2370667

As noted in my post-DrupalCon Bogotá critical issue run-down, performance improvements are a large chunk of the work remaining in Drupal 8. We had deliberately postponed most of this work until post-beta to avoid premature optimization and to allow all the major architectural chunks to be in place. However, we definitely can't release Drupal 8 while it is much slower than Drupal 7.

The D8 Accelerate fund has been instrumental in not only helping to address critical performance regressions, but also in accelerating the development of Drupal 8's next-generation cache system.

Or, to sum it up in a cheesy catch-phrase:

For less than $10,000, we're making Drupal 8 twice as fast! :D

Win!

Unblocking the beta-to-beta upgrade path

The second large focus of D8 Accelerate grants has been around D8 upgrade path blockers. These are extremely strategic, because they unblock a beta-to-beta upgrade path between Drupal 8 releases, which is extremely important for early Drupal 8 adopters.

For example, one large chunk of work D8 Accelerate has funded is in making sure Entity Field API and Views work well together. This is critical for features such as Multilingual, so content shows up in the right languages when expected, and it's necessary to complete this work prior to providing an upgrade path since it would be horrendous to write hook_update_N() functions for some of the necessary changes.

We're also exploring other alternatives to provide a beta-to-beta upgrade path to early adopters sooner, which is viable now that the hardest data-model-changing issues are done.

Security

Drupal drop on a padlock
Source: http://www.codepositive.com/code-positive/about

Obviously, we do not want to release Drupal 8 with known security vulnerabilities, but neither do we want to release an "upgrade path beta" that we encourage early adopters to use with known security vulnerabilities. Hence, we are trying to get any critical security issues taken care of sooner than later.

For example, one chunk of work that D8 Accelerate is funding in this area is tightening security around Drupal 8 entity API. Numerous form validation functions in core contain entity-level validation, to the wild dismay of anyone who's ever tried to implement web services on top of Drupal. The reason that's bad is because if you attempt to save something using just the Entity API (as you will in a REST API scenario where there are no forms), you will end up skipping validation routines and could end up with invalid and/or insecure data entry.

Targeted Sprints to Crush Criticals

Menu link critical sprint at DrupalCamp New Jersey
Source: https://groups.drupal.org/node/456353

As demonstrated at the Ghent critical issue sprint last year, nothing is better for D8's velocity than getting a bunch of awesome contributors in the same place to pound on the critical queue together. D8 Accelerate funded a fantastic Menu link critical sprint at DrupalCamp New Jersey which, in addition to turning this area of criticals from "OMGWTFBBQ" to an actionable plan, resulted directly or indirectly in all of the related critical issues in this area being closed, within a couple of weeks after the sprint.

We aim to do more of these same types of targeted sprints throughout the year, the next one being the DrupalCI sprint in a couple of weeks. More on that in a sec.

Testbot modernization

Architectural diagram of new testbot
Source: https://www.previousnext.com.au/blog/architecting-drupalci-drupalcon-ams...

Our beloved Drupal.org testbot has been showing its age. https://qa.drupal.org/ is still on Drupal 6, and largely on life-support these days. Testbot doesn't support testing on multiple PHP versions and databases, both of which are Drupal.org (websites/infra) blockers to a Drupal 8 release.

The DrupalCI: Modernizing Testbot Initiative is being driven by numerous devops-inclined community members from around the world. It aims to rebuild testbot from a collection of Drupal modules to a more standard CI stack (using big fancy words like Jenkins and Docker and Puppet and Travis and Silex) that your average PHP/devops folk can both understand and help maintain.

There's been a lot of work on DrupalCI already, and the upcoming D8 Accelerate sprint on DrupalCI: Modernizing Testbot Initiative will bring all the various contributors together to form DrupalCI Voltron to get an MVP of all the various pieces working together. Actual deployment will happen some time later, and both the new and old testbot will run alongside each other for a good while so any kinks can be worked out while D8 development stays stable.

This particular improvement not only allows Drupal 8 to ship, it also will provide great new functionality to all projects on Drupal.org! The architecture allows for ample room for later expansion as well, so we could start doing things like automated code reviews, performance testing, front-end testing, etc.

People power!

Here are some of the awesome Drupal contributors who've benefited from these funds:

Not just code!

D8 Accelerate funds are being used not only to fund development work, but also to fund patch reviews as well as more "project management"-y tasks like "triaging" a set of issues to find the truly critical ones, research on different approaches, etc. Wherever possible, the core committers explicitly look for opportunities to fund two people, usually a developer and a patch reviewer, in order to maintain the sanctity of Drupal core's peer review process.

I think this is great, because it highlights that it's not just raw PHP that's going to get Drupal 8 out the door; it's a joint effort of many complementary skills coming together.

Show me the money!

Skeptical cat is fraught with skepticism
Source: https://blackincense.files.wordpress.com/2008/10/skeptical-cat-is-fraugh...

Why $250k to accelerate D8?

This is a very reasonable question to ask, particularly in light of the widely-cited statistic of 2,750+ contributors to Drupal 8, and various Drupal companies employing major contributors to Drupal core. Here are a few points:

  1. Drupal 8 will be a truly revolutionary release, not only by providing tons more useful functionality out of the box for site builders and content authors (WYSIWYG, mobile support, Views, configuration management, etc.), but by modernizing the underlying code base to address years of technical debt, and help "future-proof" Drupal for the next 10+ years. Unsurprisingly, this means that the total amount of work that has already gone into D8, and that remains needed to move D8 from a late beta to a release, is larger than it was for earlier versions of Drupal. Most technology maturations follow that pattern.

    Drupal 8's release also unlocks the move to a new release cycle that introduces backwards-compatible feature releases every 6 months. This allows us to "release early, release often," as opposed to "release every 4+ years, coupled with lots and lots of API breaks." ;)

  2. For these reasons, as well as many others, there's significant community benefit for 8.0.0 to be released as soon as possible, both so that sites can be built on it, and so that the 8.1.x branch can be opened for development for everyone with a feature idea itch to scratch. Additionally, many organizations and individuals who would benefit from D8 getting released sooner than later don't have the expertise or time to solve the remaining critical issues. These organizations/people might be willing to contribute money, but don't know who to best send it to or don't want to deal with the administration of contracting directly with individual core contributors. This fund is an opportunity for those organizations/people to make a difference without dealing with that administration.

    Make no mistake: Drupal 8 will get done, with or without this money. The goal of the fund is not about saying that our current awesome core contributor base is incapable of completing the work; it's only a recognition that funding work can make it happen faster.

  3. Why is this so? It's a common misconception that most core developers are paid for their work, either by Drupal companies who employ them, or by their customers. In reality, those directly financially compensated for their contributions to core (and especially to Drupal 8, which is not yet commercially viable for the masses) are a tiny fraction of the overall number of contributors.

    While there are numerous contributors who have already spent literally years contributing to core during their nights and weekends, and as a result have developed the kind of expertise needed to finish some of the remaining hard critical issues, relying on their ongoing availability of free time is not sustainable. These include contributors who work as freelance developers for clients, and it's certainly unfair to expect these people to turn down paid client work in order to have free time to work on core, or to quit being freelancers and become employees of forward-thinking Drupal companies who provide company time for core contribution. One of my favorite aspects of D8 Accelerate is that it is helping to "level the playing field" by making it possible for these people to have time to work on core regardless of their current employment situation.

    In short, don't confuse "has a job" with "is paid to work on Drupal core."

  4. It's also important to emphasize here that injecting funding into the "bug fix slog" phase of major Drupal releases, when all the fun stuff that tends to motivate volunteers is long exhausted, is nothing new. That should come as no surprise, given that there have always been companies with financial interests in having a given version of Drupal ready sooner. For example, in Drupal 6, Acquia funded release manager Gábor Hojtsy full-time to help get that release done. In Drupal 7, in addition to employing core contributors full-time, Examiner.com paid numerous "bug bounties" out to folks to help slay specific critical issues. The difference here is that the DA as a non-profit organization needs to be extremely transparent in anything it's doing with the community's money, so there is greater visibility on things this time around.

If you don't want to donate, that's totally okay. You'll still be able to use Drupal 8 all you want, for free, when it's ready. Donating to this fund is only an opportunity to help make that happen sooner, if that's sufficiently valuable to you.

For a lot more "deep thinking" around these topics, see:

Many thanks to effulgentsia for his extensive help on this part!

How do you decide on how money gets spent?

The core committers have a well-documented process that explains how we decide what to fund. The TL;DR version is we look at criteria like:

  • Is a proposal genuinely a release blocker to Drupal 8, or something that will otherwise directly lead to an accelerated Drupal 8 release? (That's a biggie.)
  • Is a proposal resolving a blocker to other work, especially other release blockers?
  • Is a proposal resolving an "ecosystem" blocker? (For example "D8 upgrade path" issues that block early D8 adoption, blockers to a major portion of contributed modules/themes porting)
  • Is this a place where we can inject funding to take an issue the "last 20%" and get it across the finish line quickly?
  • Is momentum in this area slow, making it unlikely to be fixed "organically" by D8 contributors?
  • Are the people working in this area not directly funded (by an employer or client) to fix it already?
  • Do we have some confidence that funding will lead to a successful outcome?

Proposals that answer "yes" to more of these questions than not are more likely to get funded. And the D8 Accelerate team is constantly on the lookout for things that meet this criteria and proactively reaching out to contributors to help get things started.

In short, we take our responsibility with the community's money very seriously, and have turned down multiple community proposals that were fantastic ideas, but did not fit this criteria. (Where appropriate, we refer folks over to the Community Cultivation Grants instead.)

Also please note that a previous restriction around people asking for funding for their own time has been lifted a month or so back (Thanks, DA!). So if you are a contributor who knows a lot about critical issue #12345, you can request a stipend (initially capped at $500 for five hours) to help push it forward.

If that sounds like you, or you have other creative ideas on how we can get Drupal 8 out faster, apply for a grant today!

Thank you for your support!

I wanted to take the opportunity to give a huge shout-out to the "anchor donors" of the D8 Accelerate campaign:

Thanks to their efforts, every dollar you contribute is already matched by the Drupal Association and these anchor donors, doubling your impact. If you'd like, you can make a donation to my fundraising drive (I've set a very ambitious goal of $20,000 since that's 8% of $250,000 — get it? ;)):

Fundraising Websites - Crowdrise

(Note: This is just the amount in my personal fundraiser; the overall fundraiser is at $135K and counting.)

...or, find your favourite Drupal person at https://www.crowdrise.com/d8accelerate/fundraiser and donate to theirs instead, or create your own! :)

Thanks as well to the folks who somehow stumbled across it and donated to my fundraiser already—Andreas Radloff, Douglas Reith, and Ian Dunn. I thought Ian's note was particularly awesome! :D

As a WordPress developer, I think we're all on the same side and wish you the best :)

And finally, thank YOU for any and all support you can provide that will help us make Drupal 8 the most successful release of Drupal yet! :D If you have any other questions, please feel free to ask!

Mar 25 2015
Mar 25

Next week, an international conglomeration of awesome folks will convene in Portland, Oregon for a D8 Accelerate-funded sprint on DrupalCI: Modernizing Testbot Initiative.

The main aim of DrupalCI is to rebuild Drupal's current testbot infrastructure (which is currently powered by an aging Drupal 6 site) to industry-standard components such as Jenkins, Docker, and so on, architected to be generally useful outside of Drupal.org. See Nick Schuch's Architecting DrupalCI at DrupalCon Amsterdam blog post for more details.

The goal is to end the sprint with an "MVP" product on production hardware, with integration to Drupal.org, which can be used to demonstrate a full end-to-end D8 core ‘simpletest’ test run request from Drupal.org through to results appearing on the results server.

You can read and subscribe to the sprint hit-list issue to get an idea of who's going to be working on what, and the places where you too can jump in (see the much longer version for more details).

This is a particularly important initiative to help with, since it not only unblocks Drupal 8 from shipping, it also makes available awesome new testing tools for all Drupal.org projects!

Go Team! :)

Mar 24 2015
Mar 24

In honor of long-time Drupal contributor Aaron Winborn (see his recent Community Spotlight), whose battle with Amyotrophic lateral sclerosis (ALS) (also referred to as Lou Gehrig's Disease) is coming to an end later today, the Community Working Group, with the support of the Drupal Association, would like to announce the establishment of the Aaron Winborn Award.

This will be an annual award recognizing an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. It will include a scholarship and stipend to attend DrupalCon and recognition in a plenary session at the event. Part of the award will also be donated to the special needs trust to support Aaron's family on an annual basis.

Thanks to Hans Riemenschneider for the suggestion, and the Drupal Association executive board for approving this idea and budget so quickly. We feel this award is a fitting honor to someone who gave so much to Drupal both on a technical and personal level.

Thank you so much to Aaron for sharing your personal journey with all of us. It’s been a long journey, and a difficult one. You and your family are all in our thoughts.

Mar 23 2015
Mar 23

If you move to Drupal 8 from Drupal 6/7, you'll be using the new core migration system.

Migrate team lead benjy has just posted a plan to finalize the migration system, a "meta" issue which outlines what work's already been completed, what's left to be done, what's blocking what, and how to get involved.

Migrations are an extremely high-impact place to throw time and energy, so if fixing Drupal 8 release blockers isn't your thing, but being able to actually move to Drupal 8 when it's ready is, please jump in and lend a hand! :D

Mar 19 2015
Mar 19

In order to support a beta-to-beta upgrade path for Drupal 8 users sooner, the core committers have posted a proposal that recommends re-activating the http://drupal.org/project/head2head project in contrib and building the beta-to-beta upgrade path there in the short-term. This allows early adopters to have access to an upgrade path much earlier than core would be able to provide, and also gives us a "safe space" to test beta-to-beta upgrades prior to supporting them formally in core, without slowing down our current velocity on critical issue fixing.

Please share your thoughts, especially if you're one of the adventurous early adopters who are actively building on Drupal 8 already!

Feb 14 2015
Feb 14

(Apologies for the atrocious state of the HTML that follows; this content is originally from this Google Doc.)

Updated Feb 15, 2015 with "needs triage" marker, per xjm.

Webchick's "plain Drupal English" Guide to the Remaining Drupal 8 Critical Issues: DrupalCon Bogotá Edition */

DrupalCon Bogotá just finished up, and critical issue-wise we've managed to stay in the 50s for a few days (down from a high of 150 in the summer of 2013!), so now seems like as good a time as any to write down what's left to ship Drupal 8!

This post will attempt to document all of the remaining 55 criticals (as of this writing), and attempt to offer a somewhat "plain English" (or at least "Drupal English" ;)) description of each, loosely categorized into larger areas in which we could really use extra help. There are over 2,600 contributors to Drupal 8 at this time, please join us!

(Note: These descriptions might not be 100% accurate; this is my best approximation based on the issue summary and last few comments of each issue. If I got the description of your pet issue wrong, please update your issue summary. ;))

Table of contents

Quick vocabulary lesson

Current state of critical issues

Security

Security Parity with Drupal 7

Session and User Authentication API

REST

New security improvements

Performance

Profiling

Fix regressions relative to Drupal 7

Entity Field API

Views

Configuration system

"Fix it, or else"

General house-keeping

Other

Thrilling conclusion! (also known as "TL;DR")

Quick vocabulary lesson

Within this list, there are numerous "markers" used to signify that some of the issues in this list are more important to fix ASAP. These are:

  • D8 upgrade path: An issue tagged D8 upgrade path (currently, 13) means it blocks a beta-to-beta upgrade path for Drupal 8, generally because they materially impact the data schema or they impact security. Once we resolve all of these blockers, early adopters will no longer need to reinstall Drupal between beta releases, but can just run the update.php script as normal. This is currently our biggest priority.
  • Blocker: An issue tagged blocker (currently, 5) means it blocks other issues from being worked on. This is currently our second-biggest priority (or 0th priority in the case an issue blocks a D8 upgrade path issue :D). I've noted these as "sub-bullets" of the issues that are blocking them.
  • Postponed: Issues that are marked postponed (currently, 9) are either currently blocked by one of the "Blocker" issues, or we've deliberately chosen to leave off until later.
  • >30 days: These patches have a patch more than 30 days old, and/or were last meaningfully commented on >30 days ago. If you're looking for a place to start, re-rolling these is always helpful!
  • Needs triage: Anything with a Triaged D8 critical tag (33 as of today) means that at least a couple of Drupal core's branch maintainers have agreed that this issue should indeed block Drupal 8's release. Conversely, those tagged Needs D8 critical triage (11 as of today), and also those issues without either tag, are those that may or may not actually be critical and still need looking over. As a result, before dumping a bunch of time into solving these, they should be evaluated against the priority levels of issues document to see if they can be downgraded.
  • No patch: This issue doesn't have a patch yet. Oh the humanity! Want to give it a shot?

Other weird core issue nomenclature:

  • "meta" means a discussion/planning issue, with the actual patch action happening in related/child issues.
  • "PP-3" means "this issue is postponed on 3 other issues" (PP-1 means 1 other issue; you get the drift).

Current state of critical issues

Sections roughly organized from "scariest" to "least scary" in terms of how likely they are to make Drupal 8 take a longer time to come out.

Security

Because Drupal 8 hasn't shipped yet, it's not following Drupal's standard Security Advisory policy, so there are still outstanding, public security issues (13 as of this writing). We need to resolve most of these prior to providing a Drupal 8 beta-to-beta upgrade path, as this is the time when we signal to early adopters that it's an OK time to start cautiously building real sites on Drupal 8.

Skills needed: Various

Security Parity with Drupal 7

This class of security issue is to ensure that when Drupal 8 ships, it won't have any regressions security-wise relative to Drupal 7.

  • Port SA-CONTRIB-2013-096 to D8 (D8 upgrade path) Here's one such issue for Entity Reference module. SA-CONTRIB-2013-096 addressed a relatively esoteric remote access bypass bug, and the patch needs to be forward-ported to Drupal 8.
  • Port SA-CONTRIB-2015-039 to D8 (D8 upgrade path)  SA-CONTRIB-2015-039 addressed two issues in Views module, a redirect and default permissions for disabled views. The first was fixed in D8, but access checks are still missing from a few views for the second.

Session and User Authentication API

Because of various intricate dependencies, the authentication part of Drupal 8 isn't yet converted to object-oriented code, and prevents us from further optimizing bootstrap. This set of issues fixes various problems with this part of the code, and ensures these important security APIs are complete and ready to ship.

REST

  • REST user updates bypass tightened user account change validation (D8 upgrade path) Since Drupal 7, when you edit your user account, you have to provide the existing password when you want to change the password or e-mail. This security feature is currently by-passed by REST user updates as you can change the password or e-mail without providing the password.
  • External caches mix up response formats on URLs where content negotiation is in use (>30 days) Drupal 8's request processing system is currently based on content negotiation (which allows you to serve multiple versions of a document at the same URI based on what headers are sent e.g. Accept: text/html or Accept: application/json). This is generally considered the "right way" to do REST. However, various external caches and CDNs have trouble with this mechanism, and can mix them up and can send random formats back. The issue proposes changing from content negotiation to separate, distinct paths such as /node/1.json.

New security improvements

These issues affect new security improvements we want to make over and above what Drupal 7 does.

  • [meta] Document or remove every SafeMarkup::set() call One of the big security improvements in Drupal 8 is the introduction of Twig's autoescape feature, which ensures that all output to the browser is escaped by default. However, this is quite a big change that requires all of the code that was previously escaping content to stop doing that, else it gets double-escaped (so you start seeing &lt; and &quot; and whatnot in the UI). We originally introduced the ability to manually mark markup safe with SafeMarkup::set(), but the recommended approach is actually to use Twig everywhere, so this issue is to ensure that all remaining instances of the manual way are fixed, or at least documented to explain why they're using the non-recommended method.
  • Passing in #markup to drupal_render is problematic (>30 days, Needs triage) Another issue in the Twig autoescape space, we need to ensure that markup set by the "#markup" in e.g. form definitions is properly escaped.
  • Limit PDO MySQL to executing single statements if PHP supports it (Needs triage) Remember SA-CORE-2014-005? Yeah, so do we. ;) This issue is to make sure that if another SQL injection vulnerability is ever found again, the damage it can do is more limited by eliminating the ability for MySQL to execute multiple queries per PDO statement.

Performance

Tied with security, 13 of the remaining issues are tagged Performance. While it may seem odd/scary to have this be a big chunk of the work left, it's a common practice to avoid premature optimization, and instead focus on optimization once all of the foundations are in place.

Skills needed: Profiling, caching, optimization, render API

Profiling

Here are a sub-set of issues where we need performance profiling to determine what gives us the biggest bang for our effort.

Fix regressions relative to Drupal 7

  • [meta] Resolve known performance regressions in Drupal 8 This is the main tracking issue in this space. During the 8.x cycle we've introduced several known performance regressions compared to Drupal 7 (sometimes to make progress on features/functionality, other times because we introduced changes that we hoped would buy us better scalability down the line), which we need to resolve before release so that Drupal 8 isn't slower than Drupal 7. The performance team meets weekly and tracks their progress in a detailed spreadsheet.

Entity Field API

Tracked under the Entity Field API tag (currently 6 issues).

Skills needed: Entity/Field API, Form API, Schema API

  • Schema for newly defined entity types is never created (D8 upgrade path) When you first install a module that defines an entity type (for example, Comment), its database tables are correctly generated. However, if an entity definition is later added by a developer to an already-installed module, the related database schema won't get created, nor will it be detected in update.php as an out-of-date update to run.
  • FileFormatterBase should extend EntityReferenceFormatterBase (D8 upgrade path) Entity Reference fields define a EntityReferenceFormatterBase class, which contains logic about which entities to display in the lookup, including non-existing entities and autocreated entities. File field's FileFormatterBase class currently duplicates that logic, except it misses some parts, including access checking, which makes this a security issue. The issue proposes to simply make File field's base class a sub-class of Entity Reference's, removing the need of "sort of but not quite the same" code around key infrastructure.
  • FieldTypePluginManager cannot instantiate FieldType plugins, good thing TypedDataManager can instantiate just about anything Currently, you get a fatal error if you attempt to use Drupal 8's Plugin API to create a new instance of a field type. The current code in core is avoiding this problem by going roundabout via the Typed Data API instead. This issue's critical because these are two of the most central APIs in Drupal 8, and they should work as expected.
  • [META] Untie content entity validation from form validation Despite all the work to modernize Drupal 8 into a first-class REST server, there still remain places where validation is within form validation functions, rather as part of the proper entity validation API, which means REST requests (or other types of workflows that bypass form submissions) are missing validation routines. This meta issue tracks progress of moving the logic to its proper place.
  • Entity forms skip validation of fields that are edited without widgets (>30 days) If a field can be edited with a form element that is not a Field API widget, we do not validate its value at the field-level (i.e., check it against the field's constraints). Fixing this issue requires ensuring that all entity forms only use widgets for editing field values.
  • Entity forms skip validation of fields that are not in the EntityFormDisplay (No patch, >30 days) Drupal 8 has a new feature called "form modes" (basically analogous to "view modes" in Drupal 7, except allowing you to set up multiple forms for a given entity instead). Currently, we're only validating fields that are displayed on a given form mode, even though those fields might have validation constraints on other fields that are not displayed. Critical because it could present a security issue.

Views

Views issues are generally tracked with the VDC tag. There are currently 6 criticals at this point which touch on Views (some already covered in earlier sections).

Configuration system

The configuration system is remarkably close to being shippable! Only 4 critical issues left. We're now working on finalizing the niggly bits around edge cases that involve configuration that depends on other configuration.

Skills needed: Configuration system, Entity Field API, Views

"Fix it, or else"

This subset of issues are things that are part of core currently, and we would really like to keep, but are willing to make some hard choices in the event they are among the last remaining criticals blocking release. The "postponed" among this list means "postponed until we're down to only a handful of criticals left." If these issues end up remaining in the list, we will move their functionality to contrib, and hope to add it back to core in a later point release if it gets fixed up.

Skills required: Various, but mainly low-level infrastructure and non-MySQL database skills.

  • [meta] Drupal.org (websites/infra) blockers to a Drupal 8 release (Blocker) This issue contains a "grab bag" of Drupal.org blockers that prevent an optimal Drupal 8 release, including things like semantic versioning support, testing support for multiple PHP/database versions, and support for Composer-based installations. If this issue is one of the last remaining criticals, we might choose to ship Drupal 8 anyway, and jettison one or more features in the process, such as…
  • [Meta] Make Drupal 8 work with PostgreSQL (Needs triage) The meta/planning issue for fixing PostgreSQL (both in terms of functionality and in terms of failing tests). bzrudi71 is predominantly leading the charge here and making steady progress, but more hands would be greatly appreciated.
  • [meta] Database tests fail on SQLite (>30 days) Same deal as PostgreSQL but for SQLite. Unlike PostgreSQL though, this one doesn't have anyone leading the charge at this time, and it's also a lot harder to punt this to contrib, since we use it for various things such as testbot. Help wanted!

General house-keeping

These are all basic things we need to keep on top of between now and release, to ensure that when we're down to only a handful of criticals, we're ready to ship a release candidate. The good news is, these are also all generally really easy patches to make, and often also to test.

Skills needed: Basic patch rolling / reviewing / testing skills. (good for newbies!)

  • [meta] Ship minified versions of external JavaScript libraries (Postponed) Basically, in the Gilded Mobile Age™ we want to ensure that we're sending as little over the wire as possible, so scrunching various JS libraries down to the smallest possible file size needs to be the default. Separate issue from above because it needs to happen for both updated and existing JS libraries. Postponed because there'll be less work to do once all of the out-of-date JS libraries are updated and minified at the same time.

Other

I couldn't figure out a nice heading for these, so here's the rest.

  • Remove _system_path from $request->attributes (Needs triage) Symfony provides a $request object, which has an "attributes" property for the purpose of storing various contextual bits. But the problem with $request->attributes->get('_MAGIC_KEY') is that the values are undocumented, there's no IDE autocompletion, and it's not clear which are internal vs. public properties, so we have an issue at [meta] Stop using $request->attributes->get(MAGIC_KEY) as a public API. to try and stop doing that.

    However, _system_path in particular is used a ton, since it's very common to want to know the path of the current request. The patch exposes a "CurrentPath" service instead, which eliminates all of those issues.
  • Potential data loss: concurrent node edits leak through preview (Needs triage) Because the temp store that Drupal 8's new node preview system employs uses an entity's ID as the key, rather than something uniquely identifiable to a user, if two users are editing the same node and hit preview at the same time, one of them is going to lose data due to a race condition.
  • Ajax file uploads fail on IE 9 Pretty much exactly what it says on the tin. :P

Thrilling conclusion! (also known as "TL;DR")

Well, not so thrilling, but at least a conclusion. :)

  • Anywhere you see a blocker issue, attack it with fire. Those are holding other criticals up.
  • The biggest area of focus right now is D8 upgrade path blockers. Many of them are security issues.
  • Another big area is Performance, both fixing existing regressions, and profiling to determine where our biggest wins are.
  • Views and Entity Field API are tied in third place for number of remaining criticals. Let's have a race, shall we? ;)
  • The configuration system is looking pretty good, but still has a handful of sticky issues left.
  • There are a series of important features we'll lose if they're not fixed up in time.
  • If you're looking for something somewhat easy/mundane, help yourself to one of the general house-keeping issues.
  • Don't forget about the other miscellaneous issues I was too tired to categorize.
  • You're safer fixing a Triaged D8 critical issue, since those are all guaranteed to block release, while others may be downgraded in the future.

Sorry this post was so long (and probably has its share of inaccuracies) but I hope it will be helpful to some. It's basically what I needed to get back up to speed after taking a few months off of Drupal 8, so figured I'd document my way to understanding.

Now, let's get 'er done! :D

Tags: drupal 8drupaldrupal core diaries
Feb 14 2015
Feb 14

(Apologies for the atrocious state of the HTML that follows; this content is originally from this Google Doc.)

Updated Feb 15, 2015 with "needs triage" marker, per xjm.

DrupalCon Bogotá just finished up, and critical issue-wise we've managed to stay in the 50s for a few days (down from a high of 150 in the summer of 2013!), so now seems like as good a time as any to write down what's left to ship Drupal 8!

This post will attempt to document all of the remaining 55 criticals (as of this writing), and attempt to offer a somewhat "plain English" (or at least "Drupal English" ;)) description of each, loosely categorized into larger areas in which we could really use extra help. There are over 2,600 contributors to Drupal 8 at this time, please join us!

(Note: These descriptions might not be 100% accurate; this is my best approximation based on the issue summary and last few comments of each issue. If I got the description of your pet issue wrong, please update your issue summary. ;))

Quick vocabulary lesson

Current state of critical issues

Security

Security Parity with Drupal 7

Session and User Authentication API

REST

New security improvements

Performance

Profiling

Fix regressions relative to Drupal 7

Entity Field API

Views

Configuration system

"Fix it, or else"

General house-keeping

Other

Thrilling conclusion! (also known as "TL;DR")

Within this list, there are numerous "markers" used to signify that some of the issues in this list are more important to fix ASAP. These are:

  • D8 upgrade path: An issue tagged D8 upgrade path (currently, 13) means it blocks a beta-to-beta upgrade path for Drupal 8, generally because they materially impact the data schema or they impact security. Once we resolve all of these blockers, early adopters will no longer need to reinstall Drupal between beta releases, but can just run the update.php script as normal. This is currently our biggest priority.
  • Blocker: An issue tagged blocker (currently, 5) means it blocks other issues from being worked on. This is currently our second-biggest priority (or 0th priority in the case an issue blocks a D8 upgrade path issue :D). I've noted these as "sub-bullets" of the issues that are blocking them.
  • Postponed: Issues that are marked postponed (currently, 9) are either currently blocked by one of the "Blocker" issues, or we've deliberately chosen to leave off until later.
  • >30 days: These patches have a patch more than 30 days old, and/or were last meaningfully commented on >30 days ago. If you're looking for a place to start, re-rolling these is always helpful!
  • Needs triage: Anything with a Triaged D8 critical tag (33 as of today) means that at least a couple of Drupal core's branch maintainers have agreed that this issue should indeed block Drupal 8's release. Conversely, those tagged Needs D8 critical triage (11 as of today), and also those issues without either tag, are those that may or may not actually be critical and still need looking over. As a result, before dumping a bunch of time into solving these, they should be evaluated against the priority levels of issues document to see if they can be downgraded.
  • No patch: This issue doesn't have a patch yet. Oh the humanity! Want to give it a shot?

Other weird core issue nomenclature:

  • "meta" means a discussion/planning issue, with the actual patch action happening in related/child issues.
  • "PP-3" means "this issue is postponed on 3 other issues" (PP-1 means 1 other issue; you get the drift).

Sections roughly organized from "scariest" to "least scary" in terms of how likely they are to make Drupal 8 take a longer time to come out.

Security

Because Drupal 8 hasn't shipped yet, it's not following Drupal's standard Security Advisory policy, so there are still outstanding, public security issues (13 as of this writing). We need to resolve most of these prior to providing a Drupal 8 beta-to-beta upgrade path, as this is the time when we signal to early adopters that it's an OK time to start cautiously building real sites on Drupal 8.

Skills needed: Various

Security Parity with Drupal 7

This class of security issue is to ensure that when Drupal 8 ships, it won't have any regressions security-wise relative to Drupal 7.

  • Port SA-CONTRIB-2013-096 to D8 (D8 upgrade path) Here's one such issue for Entity Reference module. SA-CONTRIB-2013-096 addressed a relatively esoteric remote access bypass bug, and the patch needs to be forward-ported to Drupal 8.
  • Port SA-CONTRIB-2015-039 to D8 (D8 upgrade path)  SA-CONTRIB-2015-039 addressed two issues in Views module, a redirect and default permissions for disabled views. The first was fixed in D8, but access checks are still missing from a few views for the second.

Session and User Authentication API

Because of various intricate dependencies, the authentication part of Drupal 8 isn't yet converted to object-oriented code, and prevents us from further optimizing bootstrap. This set of issues fixes various problems with this part of the code, and ensures these important security APIs are complete and ready to ship.

REST

  • REST user updates bypass tightened user account change validation (D8 upgrade path) Since Drupal 7, when you edit your user account, you have to provide the existing password when you want to change the password or e-mail. This security feature is currently by-passed by REST user updates as you can change the password or e-mail without providing the password.
  • External caches mix up response formats on URLs where content negotiation is in use (>30 days) Drupal 8's request processing system is currently based on content negotiation (which allows you to serve multiple versions of a document at the same URI based on what headers are sent e.g. Accept: text/html or Accept: application/json). This is generally considered the "right way" to do REST. However, various external caches and CDNs have trouble with this mechanism, and can mix them up and can send random formats back. The issue proposes changing from content negotiation to separate, distinct paths such as /node/1.json.

New security improvements

These issues affect new security improvements we want to make over and above what Drupal 7 does.

  • [meta] Document or remove every SafeMarkup::set() call One of the big security improvements in Drupal 8 is the introduction of Twig's autoescape feature, which ensures that all output to the browser is escaped by default. However, this is quite a big change that requires all of the code that was previously escaping content to stop doing that, else it gets double-escaped (so you start seeing &lt; and &quot; and whatnot in the UI). We originally introduced the ability to manually mark markup safe with SafeMarkup::set(), but the recommended approach is actually to use Twig everywhere, so this issue is to ensure that all remaining instances of the manual way are fixed, or at least documented to explain why they're using the non-recommended method.
  • Passing in #markup to drupal_render is problematic (>30 days, Needs triage) Another issue in the Twig autoescape space, we need to ensure that markup set by the "#markup" in e.g. form definitions is properly escaped.
  • Limit PDO MySQL to executing single statements if PHP supports it (Needs triage) Remember SA-CORE-2014-005? Yeah, so do we. ;) This issue is to make sure that if another SQL injection vulnerability is ever found again, the damage it can do is more limited by eliminating the ability for MySQL to execute multiple queries per PDO statement.

Performance

Tied with security, 13 of the remaining issues are tagged Performance. While it may seem odd/scary to have this be a big chunk of the work left, it's a common practice to avoid premature optimization, and instead focus on optimization once all of the foundations are in place.

Skills needed: Profiling, caching, optimization, render API

Profiling

Here are a sub-set of issues where we need performance profiling to determine what gives us the biggest bang for our effort.

Fix regressions relative to Drupal 7

  • [meta] Resolve known performance regressions in Drupal 8 This is the main tracking issue in this space. During the 8.x cycle we've introduced several known performance regressions compared to Drupal 7 (sometimes to make progress on features/functionality, other times because we introduced changes that we hoped would buy us better scalability down the line), which we need to resolve before release so that Drupal 8 isn't slower than Drupal 7. The performance team meets weekly and tracks their progress in a detailed spreadsheet.

Entity Field API

Tracked under the Entity Field API tag (currently 6 issues).

Skills needed: Entity/Field API, Form API, Schema API

  • Schema for newly defined entity types is never created (D8 upgrade path) When you first install a module that defines an entity type (for example, Comment), its database tables are correctly generated. However, if an entity definition is later added by a developer to an already-installed module, the related database schema won't get created, nor will it be detected in update.php as an out-of-date update to run.
  • FileFormatterBase should extend EntityReferenceFormatterBase (D8 upgrade path) Entity Reference fields define a EntityReferenceFormatterBase class, which contains logic about which entities to display in the lookup, including non-existing entities and autocreated entities. File field's FileFormatterBase class currently duplicates that logic, except it misses some parts, including access checking, which makes this a security issue. The issue proposes to simply make File field's base class a sub-class of Entity Reference's, removing the need of "sort of but not quite the same" code around key infrastructure.
  • FieldTypePluginManager cannot instantiate FieldType plugins, good thing TypedDataManager can instantiate just about anything Currently, you get a fatal error if you attempt to use Drupal 8's Plugin API to create a new instance of a field type. The current code in core is avoiding this problem by going roundabout via the Typed Data API instead. This issue's critical because these are two of the most central APIs in Drupal 8, and they should work as expected.
  • [META] Untie content entity validation from form validation Despite all the work to modernize Drupal 8 into a first-class REST server, there still remain places where validation is within form validation functions, rather as part of the proper entity validation API, which means REST requests (or other types of workflows that bypass form submissions) are missing validation routines. This meta issue tracks progress of moving the logic to its proper place.
  • Entity forms skip validation of fields that are edited without widgets (>30 days) If a field can be edited with a form element that is not a Field API widget, we do not validate its value at the field-level (i.e., check it against the field's constraints). Fixing this issue requires ensuring that all entity forms only use widgets for editing field values.
  • Entity forms skip validation of fields that are not in the EntityFormDisplay (No patch, >30 days) Drupal 8 has a new feature called "form modes" (basically analogous to "view modes" in Drupal 7, except allowing you to set up multiple forms for a given entity instead). Currently, we're only validating fields that are displayed on a given form mode, even though those fields might have validation constraints on other fields that are not displayed. Critical because it could present a security issue.

Views

Views issues are generally tracked with the VDC tag. There are currently 6 criticals at this point which touch on Views (some already covered in earlier sections).

Configuration system

The configuration system is remarkably close to being shippable! Only 4 critical issues left. We're now working on finalizing the niggly bits around edge cases that involve configuration that depends on other configuration.

Skills needed: Configuration system, Entity Field API, Views

"Fix it, or else"

This subset of issues are things that are part of core currently, and we would really like to keep, but are willing to make some hard choices in the event they are among the last remaining criticals blocking release. The "postponed" among this list means "postponed until we're down to only a handful of criticals left." If these issues end up remaining in the list, we will move their functionality to contrib, and hope to add it back to core in a later point release if it gets fixed up.

Skills required: Various, but mainly low-level infrastructure and non-MySQL database skills.

  • [meta] Drupal.org (websites/infra) blockers to a Drupal 8 release (Blocker) This issue contains a "grab bag" of Drupal.org blockers that prevent an optimal Drupal 8 release, including things like semantic versioning support, testing support for multiple PHP/database versions, and support for Composer-based installations. If this issue is one of the last remaining criticals, we might choose to ship Drupal 8 anyway, and jettison one or more features in the process, such as…
  • [Meta] Make Drupal 8 work with PostgreSQL (Needs triage) The meta/planning issue for fixing PostgreSQL (both in terms of functionality and in terms of failing tests). bzrudi71 is predominantly leading the charge here and making steady progress, but more hands would be greatly appreciated.
  • [meta] Database tests fail on SQLite (>30 days) Same deal as PostgreSQL but for SQLite. Unlike PostgreSQL though, this one doesn't have anyone leading the charge at this time, and it's also a lot harder to punt this to contrib, since we use it for various things such as testbot. Help wanted!

General house-keeping

These are all basic things we need to keep on top of between now and release, to ensure that when we're down to only a handful of criticals, we're ready to ship a release candidate. The good news is, these are also all generally really easy patches to make, and often also to test.

Skills needed: Basic patch rolling / reviewing / testing skills. (good for newbies!)

  • [meta] Ship minified versions of external JavaScript libraries (Postponed) Basically, in the Gilded Mobile Age™ we want to ensure that we're sending as little over the wire as possible, so scrunching various JS libraries down to the smallest possible file size needs to be the default. Separate issue from above because it needs to happen for both updated and existing JS libraries. Postponed because there'll be less work to do once all of the out-of-date JS libraries are updated and minified at the same time.

Other

I couldn't figure out a nice heading for these, so here's the rest.

  • Remove _system_path from $request->attributes (Needs triage) Symfony provides a $request object, which has an "attributes" property for the purpose of storing various contextual bits. But the problem with $request->attributes->get('_MAGIC_KEY') is that the values are undocumented, there's no IDE autocompletion, and it's not clear which are internal vs. public properties, so we have an issue at [meta] Stop using $request->attributes->get(MAGIC_KEY) as a public API. to try and stop doing that.

    However, _system_path in particular is used a ton, since it's very common to want to know the path of the current request. The patch exposes a "CurrentPath" service instead, which eliminates all of those issues.

  • Potential data loss: concurrent node edits leak through preview (Needs triage) Because the temp store that Drupal 8's new node preview system employs uses an entity's ID as the key, rather than something uniquely identifiable to a user, if two users are editing the same node and hit preview at the same time, one of them is going to lose data due to a race condition.
  • Ajax file uploads fail on IE 9 Pretty much exactly what it says on the tin. :P

Well, not so thrilling, but at least a conclusion. :)

  • Anywhere you see a blocker issue, attack it with fire. Those are holding other criticals up.
  • The biggest area of focus right now is D8 upgrade path blockers. Many of them are security issues.
  • Another big area is Performance, both fixing existing regressions, and profiling to determine where our biggest wins are.
  • Views and Entity Field API are tied in third place for number of remaining criticals. Let's have a race, shall we? ;)
  • The configuration system is looking pretty good, but still has a handful of sticky issues left.
  • There are a series of important features we'll lose if they're not fixed up in time.
  • If you're looking for something somewhat easy/mundane, help yourself to one of the general house-keeping issues.
  • Don't forget about the other miscellaneous issues I was too tired to categorize.
  • You're safer fixing a Triaged D8 critical issue, since those are all guaranteed to block release, while others may be downgraded in the future.

Sorry this post was so long (and probably has its share of inaccuracies) but I hope it will be helpful to some. It's basically what I needed to get back up to speed after taking a few months off of Drupal 8, so figured I'd document my way to understanding.

Now, let's get 'er done! :D

May 09 2014
May 09

Greetings from your friendly neighbourhood Drupal.org Software Working Group!

https://drupal.org/node/2261945 has a proposal + mockups on a new way to handle feature requests for Drupal.org in order to help both the Drupal.org Software Working Group and other working groups prioritize the feature roadmap for Drupal.org. Since this tool will become the method through which the Drupal community (in the widest sense of the word) makes known their Drupal.org needs/wants/desires, we'd love to hear your comments and feedback on the proposal.

Community feedback period is open until May 18th, as we're hoping to have an initial version of this tool ready by Austin.

Mar 24 2014
Mar 24

TL;DR I passed. :P Here's a run-down of what the experience was like.

Up-front disclaimer: I work for Acquia. However, I was not involved in the creation of Acquia Certification and had no insight to the test beforehand apart from a single sample question. I'm also writing this on my personal blog, rather than Acquia.com, because these are *my* thoughts/impressions, and haven't been vetted by anyone else. :) Carry on!

Some background

I'm originally from the United States (Duck, Duck, Gray Duck represent!) and moved to Canada in my early 20s to be with my now wife of 15 years. :) I had no family in Canada and very little work experience, so my only option was to come into Canada as a student. As a foreign student in Canada, you are only allowed to earn money through a job at the school you're attending. So, since I was already a huge nerd who'd been building all of my family's computers since I was a teenager, I knuckled down and got my A+ Certification and then taught computer hardware and A+ prep courses in the evenings.

So while I empathize with detractors of certification, and I'm sure lots of people would criticize A+ Certification in particular—and they'd pretty much be right on all counts—I do think certifications have their place. For me, it was an important enabler at a time when I was young and unestablished in my career, which allowed me to combine what I already knew from hands-on experience with a bit of book-cramming to get a piece of paper that allowed me to get a quite decent job. Many of the people I taught were older adults doing late-life career changes, or younger people like me trying to augment skills and knowledge they'd acquired as hobbyists into something that could be meaningful to a prospective employer (or at least their HR department).

My interest in teaching is also what got me into Drupal in the first place. During Google Summer of Code in 2005, Drupal stood out among the list of mentoring organizations, not just because I'd seen it used on the old Spread Firefox website (which originally put Drupal on my radar), but also because one of the GSoC project ideas was the Quiz module, which could help educators like me deliver web-based learning built on open source software. Cool! So I applied to write Quiz module for Drupal, and lo-and-behold that decision seems to have worked out pretty well. ;)

However, although I've been very active in the Drupal community for almost 10 years(!), the last time I actually built a Drupal site of any level of seriousness was back in the Drupal 6 era, circa 2009. In late 2008, I was becoming more of a "project manager" at work while at the same time I was appointed Drupal 7 core co-maintainer (which basically made me a "project manager" in the community as well), so although I read lots and lots of code, my knowledge of day-to-day troubleshooting of "real world" problems on Drupal sites is on much shakier ground these days. OTOH, I could tell you the reason behind almost every weird inconsistency in core, and also the names of all the main core developers' pets, so you know, there's that. ;)

So, basically, I have a background in both taking and delivering training around certification, so I was of course intrigued to see what Acquia's take on Drupal certification was all about, and how it compared. I was also very curious how I would do on this exam, given I have several years of hard-fought "real world" experience on Drupal 4.6 => Drupal 6, but then much more academic (although deeply academic, since I read most of the core patches at one point or another) knowledge of Drupal 7, though a lot of it lost to the fog of Drupal 8, where we're actively removing most of that stuff. ;)

Preparation

Start by taking a look at the Acquia Certified Developer Exam Blueprint which nicely outlines the "domains" (subject matter) that the test covers:

Domain 1.0: Fundamental Web Development Concepts

1.1. Demonstrate knowledge of HTML and CSS
1.2. Identify PHP programing concepts
1.3. Identify JavaScript and jQuery programing concepts
1.4. Demonstrate the use of Git for version control

Domain 2.0: Site Building

2.1 Demonstrate ability to create and configure Content Types with appropriate fields and field settings for building basic data structures
2.2. Demonstrate ability to configure field display and view modes for content types
2.3 Demonstrate ability to create and use Taxonomy vocabularies and terms for classification and organization of content
2.4 Demonstrate ability to configure Blocks for building layouts from information widgets
2.5 Demonstrate ability to build main and alternative navigation systems by using Menus
2.6 Demonstrate ability to create and configure Views for building content list pages, blocks and feeds

Domain 3.0: Front end development (theming)

3.1 Given a scenario, demonstrate ability to create a custom theme or sub theme
3.2 Demonstrate knowledge of theming concepts
3.3 Demonstrate ability to build or override PHP templates for defining layout content
3.4 Demonstrate ability to use theme () functions for overriding custom output
3.5 Demonstrate ability to write template pre-process functions for overriding custom output

Domain 4.0: Back end development (coding)

4.1 Demonstrate ability to develop Custom Modules using Drupal API for extending Drupal functionality
4.2 Demonstrate ability to work with Drupal's Database Abstraction Layer for managing tables and CRUD operations on data
4.3 Demonstrate ability to debug code and troubleshoot site problems
4.4 Demonstrate ability to write code using Drupal Coding Standards
4.5 Demonstrate ability to analyze and resolve site performance issues arising from site configuration and custom code
4.6 Demonstrate ability to analyze and resolve security issues arising from site configuration and custom code

My impression of this curriculum-wise is that it's a pretty complete list. If someone actually has knowledge of all of these concepts, as well as a couple of years experience learning what to do / what not to do in practical terms, they'd be a really decent, well-rounded Drupal developer.

One thing I'd love to see in future revisions of the exam is a "Community" domain that demonstrates knowledge of how to engage and participate in the Drupal community. I terms of overall Drupal success, community interaction is just as fundamental a skill as knowing how to properly debug code or troubleshoot site problems, in my experience.

I've attached a "study guide" to the bottom of this post, which I prepared by going around and gathering links to free resources under each of these headings in case it's helpful to other folks rounding out their skills. (In particular, I needed to study up on performance and JavaScript, for example.) Since I prepared this before taking the exam, I don't think it will give anyone any particular advantage, but it'll at least save you a good half hour of Googling. :)

Exam pre-requisites

A couple of things you need to know ahead of time:

1) There are two ways you can take the exam: either in "real life" through one of Kryterion's worldwide test centers, or online "proctored" exam via Web Assessor.

(Note: "Proctored" sounds like something horrible that might happen to you at a doctor's office, but it means "supervised" — they are going to record your face and your computer movements while you take the test and this will be reviewed by a human to make sure you're not cheating.)

2) Whether you take it in real life or online, you *must* schedule a time for the exam at least 24 hours in advance (my bad — thanks, Wayne Eaker!). You do that at Acquia Certification Program site:

  • Register for an account
  • Pick the exam style you want ("onsite" vs "online" — be careful to click on the right one, the distinction is very subtle ;))
  • Pay for it ($250, which puts it more on the low end... A+ is about $200 vs. Cisco/Microsoft which can be upwards of $1500). Unless of course you work for Acquia, since employees can get vouchers to take the exam for free. (Did I mention we're hiring? ;))
  • Pick a date/time.

3) If you're doing the online method, you also need to download and install a software called "Sentinel Secure" to record your webcam/microphone/screen during the test (and this needs to be installed on your actual machine, not in e.g a virtual machine, since you could very easily cheat on the host machine if that were the case), as well as provide a "biometric profile." This involves typing your name like 12 times on the keyboard, and then taking a picture of your face via your web cam (you're required to have a web cam to take the test).

If all of that sounds overly creepy to you, you should register for a real-life exam instead. ;)

Taking the exam

I went the online route, and here's what that experience was like.

First, remember that you need to be at the computer the entire time until you finish the 60 question exam, which means up to 90 minutes. And while that sounds like plenty of time, the questions often require reading and re-reading to make sure you have all the details before picking an answer. So make sure you are properly hydrated, caffeinated, and have urinated ;) before your test time.

Also, make sure you are in a quiet place and don't have any "real life" distractions happening during that 90 minutes. Web Assessor doesn't mess around. For example, a co-worker had to re-take the exam because he took the test in an office setting where people were seen walking behind his desk (because they could've been looking at his screen and whispering answers to him, presumably). For my part, I started mumbling along as I was reading a question and it gave me a warning to not read the test questions aloud. :P I'm sure if I'd kept that up, I would've had to do a force-retake as well.

Then, close out of everything except for Firefox, IE, or Safari (for whatever bizarre reason you can't use Chrome). Log back into the Acquia Certification Program site and you should see a link to your exam that becomes active within a few minutes of your test time.

(Note: If you're like me and you do a dumb thing and accidentally pick the wrong date for your exam, you will find Kryterion's support actually helpful. I was able to call an 866 number and get a person on the phone within 30 seconds, and they had me up and rescdeduled in about 2 minutes. w00t!)

Once in, it'll repeat your bio profile, you'll have to agree to a terms of use which basically says you're not allowed to talk about what's on the exam (so I'll be very vague about it here), and then you're off to the races.

All questions are multiple choice. Most are single-answer, but a few are multiple answer. On any question you're allowed to check a box and "flag" it for later review, so if you're not sure of something you can always come back to it. You can review all of your answers at any time, the ones you've flagged will be starred so they stand out.

Then at the end, you'll get your mark, as well as a breakdown of how you did per-domain, and you get this e-mailed to you as well (since obviously you can't take screenshots or copy/paste out of the Secure Sentinel app :P). A few minutes later you'll also get a fancy certificate to print out and badge for your website e-mailed to you as well.

Blah, blah, blah. How'd you do already?

I got.... 85%! Which I was actually pretty happy with, especially since I've been told the highest exam mark atm is under 90%. :) (I did the worst on the "Basic Web Concepts" part. Damn you, CSS/JS.) Overall I'd say about 30% of the questions were easy for me, another 50% made me go "Hmmm" and about 20% I needed to flag, a handful of which required resorting to Wild Ass Guesses. ;)

The reason I was able to score relatively high despite my lack of extensive hands-on D7 experience is that most of the questions on the exam are "scenarios" that are highly focused around common issues you hit in the "real world" while building Drupal sites, and most of these are pretty timeless (especially the site builder-related topics). This also makes the exam much harder to "book-cram" for, because unless you've smacked your head into the desk a few times with Drupal, you could have a hard time because all of the answers at least sound plausible.

I found this format very refreshing and very unlike the A+ certification, which was to a large extent (at least back when I took it) a bunch of mindless memorization of useless facts. For example, I will forever have the number of pins in an IDE vs. floppy cable etched into my memory, even though that is completely useless knowledge because you know what? One fits, and the other one doesn't. :P~ So don't expect your ability to recite all of the hook_menu() bitmask flags from memory to help you much on this exam. (Darn, I had worked so hard on developing that party trick, too.)

I also did spot a few typos and some places where question wording could be more clear, and I'll try and work with the certification team to clean those up (it'd be nice if there was a "report a problem with this question" link for things like that). But overall, this seems like a pretty solid entry point into certification for Drupal, and I'm looking forward to see what the team comes up with for the more focused and "hardcore" exams.

Do you need to take this exam? If you've worked on Alexa top 1000 sites and/or have a great track record of public contributions on Drupal.org, obviously no: your resume speaks for itself. But if you've been prevented by either personal or professional circumstances from having built up a robust D.o profile or client base over the years, this certification seems like a pretty solid way to get your foot in the door at a Drupal company.

\m/

Mar 24 2014
Mar 24

TL;DR I passed. :P Here's a run-down of what the experience was like.

Up-front disclaimer: I work for Acquia. However, I was not involved in the creation of Acquia Certification and had no insight to the test beforehand apart from a single sample question. I'm also writing this on my personal blog, rather than Acquia.com, because these are *my* thoughts/impressions, and haven't been vetted by anyone else. :) Carry on!

Some background

I'm originally from the United States (Duck, Duck, Gray Duck represent!) and moved to Canada in my early 20s to be with my now wife of 15 years. :) I had no family in Canada and very little work experience, so my only option was to come into Canada as a student. As a foreign student in Canada, you are only allowed to earn money through a job at the school you're attending. So, since I was already a huge nerd who'd been building all of my family's computers since I was a teenager, I knuckled down and got my A+ Certification and then taught computer hardware and A+ prep courses in the evenings.

So while I empathize with detractors of certification, and I'm sure lots of people would criticize A+ Certification in particular—and they'd pretty much be right on all counts—I do think certifications have their place. For me, it was an important enabler at a time when I was young and unestablished in my career, which allowed me to combine what I already knew from hands-on experience with a bit of book-cramming to get a piece of paper that allowed me to get a quite decent job. Many of the people I taught were older adults doing late-life career changes, or younger people like me trying to augment skills and knowledge they'd acquired as hobbyists into something that could be meaningful to a prospective employer (or at least their HR department).

My interest in teaching is also what got me into Drupal in the first place. During Google Summer of Code in 2005, Drupal stood out among the list of mentoring organizations, not just because I'd seen it used on the old Spread Firefox website (which originally put Drupal on my radar), but also because one of the GSoC project ideas was the Quiz module, which could help educators like me deliver web-based learning built on open source software. Cool! So I applied to write Quiz module for Drupal, and lo-and-behold that decision seems to have worked out pretty well. ;)

However, although I've been very active in the Drupal community for almost 10 years(!), the last time I actually built a Drupal site of any level of seriousness was back in the Drupal 6 era, circa 2009. In late 2008, I was becoming more of a "project manager" at work while at the same time I was appointed Drupal 7 core co-maintainer (which basically made me a "project manager" in the community as well), so although I read lots and lots of code, my knowledge of day-to-day troubleshooting of "real world" problems on Drupal sites is on much shakier ground these days. OTOH, I could tell you the reason behind almost every weird inconsistency in core, and also the names of all the main core developers' pets, so you know, there's that. ;)

So, basically, I have a background in both taking and delivering training around certification, so I was of course intrigued to see what Acquia's take on Drupal certification was all about, and how it compared. I was also very curious how I would do on this exam, given I have several years of hard-fought "real world" experience on Drupal 4.6 => Drupal 6, but then much more academic (although deeply academic, since I read most of the core patches at one point or another) knowledge of Drupal 7, though a lot of it lost to the fog of Drupal 8, where we're actively removing most of that stuff. ;)

Preparation

Start by taking a look at the Acquia Certified Developer Exam Blueprint which nicely outlines the "domains" (subject matter) that the test covers:

Domain 1.0: Fundamental Web Development Concepts

1.1. Demonstrate knowledge of HTML and CSS
1.2. Identify PHP programing concepts
1.3. Identify JavaScript and jQuery programing concepts
1.4. Demonstrate the use of Git for version control

Domain 2.0: Site Building

2.1 Demonstrate ability to create and configure Content Types with appropriate fields and field settings for building basic data structures
2.2. Demonstrate ability to configure field display and view modes for content types
2.3 Demonstrate ability to create and use Taxonomy vocabularies and terms for classification and organization of content
2.4 Demonstrate ability to configure Blocks for building layouts from information widgets
2.5 Demonstrate ability to build main and alternative navigation systems by using Menus
2.6 Demonstrate ability to create and configure Views for building content list pages, blocks and feeds

Domain 3.0: Front end development (theming)

3.1 Given a scenario, demonstrate ability to create a custom theme or sub theme
3.2 Demonstrate knowledge of theming concepts
3.3 Demonstrate ability to build or override PHP templates for defining layout content
3.4 Demonstrate ability to use theme () functions for overriding custom output
3.5 Demonstrate ability to write template pre-process functions for overriding custom output

Domain 4.0: Back end development (coding)

4.1 Demonstrate ability to develop Custom Modules using Drupal API for extending Drupal functionality
4.2 Demonstrate ability to work with Drupal's Database Abstraction Layer for managing tables and CRUD operations on data
4.3 Demonstrate ability to debug code and troubleshoot site problems
4.4 Demonstrate ability to write code using Drupal Coding Standards
4.5 Demonstrate ability to analyze and resolve site performance issues arising from site configuration and custom code
4.6 Demonstrate ability to analyze and resolve security issues arising from site configuration and custom code

My impression of this curriculum-wise is that it's a pretty complete list. If someone actually has knowledge of all of these concepts, as well as a couple of years experience learning what to do / what not to do in practical terms, they'd be a really decent, well-rounded Drupal developer.

One thing I'd love to see in future revisions of the exam is a "Community" domain that demonstrates knowledge of how to engage and participate in the Drupal community. I terms of overall Drupal success, community interaction is just as fundamental a skill as knowing how to properly debug code or troubleshoot site problems, in my experience.

I've attached a "study guide" to the bottom of this post, which I prepared by going around and gathering links to free resources under each of these headings in case it's helpful to other folks rounding out their skills. (In particular, I needed to study up on performance and JavaScript, for example.) Since I prepared this before taking the exam, I don't think it will give anyone any particular advantage, but it'll at least save you a good half hour of Googling. :)

Exam pre-requisites

A couple of things you need to know ahead of time:

1) There are two ways you can take the exam: either in "real life" through one of Kryterion's worldwide test centers, or online "proctored" exam via Web Assessor.

(Note: "Proctored" sounds like something horrible that might happen to you at a doctor's office, but it means "supervised" — they are going to record your face and your computer movements while you take the test and this will be reviewed by a human to make sure you're not cheating.)

2) Whether you take it in real life or online, you *must* schedule a time for the exam at least 24 hours in advance (my bad — thanks, Wayne Eaker!). You do that at Acquia Certification Program site:

  • Register for an account
  • Pick the exam style you want ("onsite" vs "online" — be careful to click on the right one, the distinction is very subtle ;))
  • Pay for it ($250, which puts it more on the low end... A+ is about $200 vs. Cisco/Microsoft which can be upwards of $1500). Unless of course you work for Acquia, since employees can get vouchers to take the exam for free. (Did I mention we're hiring? ;))
  • Pick a date/time.

3) If you're doing the online method, you also need to download and install a software called "Sentinel Secure" to record your webcam/microphone/screen during the test (and this needs to be installed on your actual machine, not in e.g a virtual machine, since you could very easily cheat on the host machine if that were the case), as well as provide a "biometric profile." This involves typing your name like 12 times on the keyboard, and then taking a picture of your face via your web cam (you're required to have a web cam to take the test).

If all of that sounds overly creepy to you, you should register for a real-life exam instead. ;)

Taking the exam

I went the online route, and here's what that experience was like.

First, remember that you need to be at the computer the entire time until you finish the 60 question exam, which means up to 90 minutes. And while that sounds like plenty of time, the questions often require reading and re-reading to make sure you have all the details before picking an answer. So make sure you are properly hydrated, caffeinated, and have urinated ;) before your test time.

Also, make sure you are in a quiet place and don't have any "real life" distractions happening during that 90 minutes. Web Assessor doesn't mess around. For example, a co-worker had to re-take the exam because he took the test in an office setting where people were seen walking behind his desk (because they could've been looking at his screen and whispering answers to him, presumably). For my part, I started mumbling along as I was reading a question and it gave me a warning to not read the test questions aloud. :P I'm sure if I'd kept that up, I would've had to do a force-retake as well.

Then, close out of everything except for Firefox, IE, or Safari (for whatever bizarre reason you can't use Chrome). Log back into the Acquia Certification Program site and you should see a link to your exam that becomes active within a few minutes of your test time.

(Note: If you're like me and you do a dumb thing and accidentally pick the wrong date for your exam, you will find Kryterion's support actually helpful. I was able to call an 866 number and get a person on the phone within 30 seconds, and they had me up and rescdeduled in about 2 minutes. w00t!)

Once in, it'll repeat your bio profile, you'll have to agree to a terms of use which basically says you're not allowed to talk about what's on the exam (so I'll be very vague about it here), and then you're off to the races.

All questions are multiple choice. Most are single-answer, but a few are multiple answer. On any question you're allowed to check a box and "flag" it for later review, so if you're not sure of something you can always come back to it. You can review all of your answers at any time, the ones you've flagged will be starred so they stand out.

Then at the end, you'll get your mark, as well as a breakdown of how you did per-domain, and you get this e-mailed to you as well (since obviously you can't take screenshots or copy/paste out of the Secure Sentinel app :P). A few minutes later you'll also get a fancy certificate to print out and badge for your website e-mailed to you as well.

Blah, blah, blah. How'd you do already?

I got.... 85%! Which I was actually pretty happy with, especially since I've been told the highest exam mark atm is under 90%. :) (I did the worst on the "Basic Web Concepts" part. Damn you, CSS/JS.) Overall I'd say about 30% of the questions were easy for me, another 50% made me go "Hmmm" and about 20% I needed to flag, a handful of which required resorting to Wild Ass Guesses. ;)

The reason I was able to score relatively high despite my lack of extensive hands-on D7 experience is that most of the questions on the exam are "scenarios" that are highly focused around common issues you hit in the "real world" while building Drupal sites, and most of these are pretty timeless (especially the site builder-related topics). This also makes the exam much harder to "book-cram" for, because unless you've smacked your head into the desk a few times with Drupal, you could have a hard time because all of the answers at least sound plausible.

I found this format very refreshing and very unlike the A+ certification, which was to a large extent (at least back when I took it) a bunch of mindless memorization of useless facts. For example, I will forever have the number of pins in an IDE vs. floppy cable etched into my memory, even though that is completely useless knowledge because you know what? One fits, and the other one doesn't. :P~ So don't expect your ability to recite all of the hook_menu() bitmask flags from memory to help you much on this exam. (Darn, I had worked so hard on developing that party trick, too.)

I also did spot a few typos and some places where question wording could be more clear, and I'll try and work with the certification team to clean those up (it'd be nice if there was a "report a problem with this question" link for things like that). But overall, this seems like a pretty solid entry point into certification for Drupal, and I'm looking forward to see what the team comes up with for the more focused and "hardcore" exams.

Do you need to take this exam? If you've worked on Alexa top 1000 sites and/or have a great track record of public contributions on Drupal.org, obviously no: your resume speaks for itself. But if you've been prevented by either personal or professional circumstances from having built up a robust D.o profile or client base over the years, this certification seems like a pretty solid way to get your foot in the door at a Drupal company.

\m/

Jan 14 2014
Jan 14

Welcome! For Drupal's 13th birthday, in addition to Give Drupal a Birthday Present: Tackle a D8 Issue!, we wanted to celebrate the occasion with a retrospective of the year 2013 as it relates to Drupal core development!

Here are some stats to get us started:

  • 1,120 unique Drupal 8 patch contributors during 2013, bringing the total number of contributors for the release to over 1,800!
  • 4,175 Drupal 8 core patches committed (even with one core maintainer on leave for several months).
  • Nearly 10,000 automated test assertions added, bringing our total to nearly 60,000 tests!
  • Over 60,000 lines of documentation added (and for the record, less than 2% of our lines of documentation are {@inheritdoc}). :P

A tag cloud showing the top Drupal 8 contributors

On the whole, 2013 represented a major shift in the Drupal 8 codebase toward modern best practices. Most core systems now use interfaces and classed objects for better developer experience. Sprawling procedural include files have largely been converted to self-contained component classes, and the new Drupal 8 plugin system is now used consistently for pluggable systems. ;)

2013 also saw some fantastic improvements for Drupal site builders, themers, and site users. At the beginning of the year, Views was in core, but core didn't use it. Now, 3 admin listings, 2 RSS feeds, 3 blocks, and the front page content listing are all views. We've added a WYSIWYG editor, several new configurable field types including Entity Reference field, configurable form modes to allow customizing of data entry forms, and a new theme templating system, Twig.

Finally, we made Drupal core truly multilingual in 2013. At the start of the year, node titles and the site name were not translatable -- now, Drupal 8 core is more translatable than Drupal 7 with all of contrib, and translations can be downloaded right away on installation.

Amazing work, everyone!

Here's a month-by-month breakdown of the milestone events and patches of 2013.

Jan 2013

On January 15, Drupal turned 12! The Blocks and Layouts, Web Services, and Multilingual initiatives also hit several important milestones.

Milestone issues

  • #1535868: Blocks converted to plugins
  • #1848490: Import translations automatically during install
  • #1866610: Configuration schemas
  • #1874500: CMF-based routing component

Feb 2013

After switching from Aloha to CKEditor, the long-awaited WYSIWYG in core issue landed. Hooray!

DrupalCon Sydney

Twig sprint at DrupalCon Sydney on the patio with a whiteboard

Sprinting Sydney style, in the sunshine with an ocean view
Photo credit: xjm

In Feburary, leading up to the end of Feature completion phase, there was a rocking code sprint in the sun at DrupalCon Sydney!

In between working on patches, conference attendees actually went outdoors once in awhile to enjoy the sun.

Druplicon, drawn in the sand on Coogee Beach.
Even Druplicon came to play in the sand!
Photo credit: xjm

Milestone issues

March 2013

March saw the commit of PHPUnit following work at the DrupalCon Sydney code sprint. (Since then, we've added 1240 assertions in 164 PHPUnit test classes!). We also converted the very first core listing page (the /node front page) to a view!

Milestone issues

  • #1732730: Converted all entity fields to new Entity Field API
  • #1901670: PHPUnit added to core.
  • #1806334: Node frontpage converted to a view
  • #1875086: Improve DX of drupal_container()->get()

April 2013

In April, alexpott joined the Drupal 8 core maintainer team. Since he started, Alex has committed nearly half of all Drupal 8 core patches. The epic patch to convert fields to CMI was committed a week later (the next big test of Drupal 8's new configuration system after Views was added to core in 2012).

Milestone issues

  • #1862398 Replace drupal_http_request() with Guzzle.
  • #1735118: Fields converted to CMI
  • #1935538: Switch REST to default to HAL.
  • #1971384: Efforts begin to port all core page callbacks to the new Drupal 8 routing system (a.k.a. "Converting Drupal 8 to Drupal 8")

May 2013

DrupalCon Portland

Key contributors sit around a table discussing hard problems.
The Portland "Hard Problems" discussions
Photo credit: Amazee Labs

Several days of in-depth technical discussions before the start of the conference. This was the largest DrupalCon sprint ever, with over 650 participants!

Check out the spike from @DrupalCon Portland sprints on this graph! By FAR the highest core participation in 2 years. pic.twitter.com/5dSSjT9H3P

— xjm (@xjmdrupal) June 5, 2013

Of particular note, the Twig sprint at DrupalCon Portland was amazing to behold. Tons of themers and front-end developers worked together in a massive push to convert core templates to Twig well before the API freeze deadline.

Milestone issues

  • #1987510: Convert all template files to Twig
  • #1498674: Make all node properties translatable
 _________________________________________
/ Committed and pushed to 8.x. Thanks!    \
| Thanks plach, das-peter, Schnitzel,     |
| dawehner, YesCT, attiks, Berdir, Gábor |
| Hojtsy, Soul88, Carsten Müller. You    |
\ are awesome!                            /
 -----------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

June 2013

Lots of hard work on technical debt between DrupalCon Portland and API freeze. More major issues fixed than any other month of the 8.x cycle, and a near-record for criticals.

DevDays Dublin

Sprinters at tables at the Dublin Institute of Technology
DevDays Dublin sprint room
Photo credit: @m_aaark

Drupal Developer Days Dublin hosted a week-long codesprint leading up to the start of Drupal 8's API freeze.
comm-press put together a great video interviewing DevDays attendees about what they're most excited about in Drupal 8:

Milestone issues

  • #1851086: admin/people converted to a view
  • #1895160: admin/content converted to a view
  • #1337554: Redesign the installer
  • #2014821: Introduced a UI for configurable form modes (huge win for site builders!)

July 2013

July 1 marked the beginning of API freeze. As a result, focus shifted to finishing in-progress API conversions, including Twig and theme layer improvements, conversions to the new-style form and page controllers introduced by the WSCCI initiative, and porting things over to the new configuration system.

Milestone issues

  • #1963544: Aggregator RSS feed converted to a view.
  • #2021817: Field widgets and formatters work on everything! (Entity base fields like titles as well as configurable fields).
  • #1784234: Schema.org support in RDF

August 2013

By August, attention had started turning towards Developer Experience (DX) improvements, and an examination of what API changes were left outstanding to complete prior to Drupal 8.0.

Midwest Developer Summit

Sprinters at the Palatir office discuss a range of topics
Midwest Developer Summit at Palantir's offices
Photo credit: eatings

The Midwest Developer Summit was a three-day, supercharged developer sprint: No sessions, no booths, no distractions. There were sprints on everything from media to web services, and Dries worked with several core issue queue wranglers to approve each proposed API change -- or not, with the goal of finishing Drupal 8's APIs, to move away from adding new things and toward release.

A list of potential features for the Drupal testing infrastructure written on a whiteboard, ordered and prioritized.
Testbot brainstorm whiteboard
Photo credit: xjm

Milestone issues

September 2013

DrupalCon Prague

The Prague city skyline

View from the Prague coder lounge
Photo credit: xjm

DrupalCon Prague was a landmark event for Drupal 8. Core maintainers announced the Migrate in core initiative live and that core would provide a D6 to D8 migration path:

If you've just built a Drupal 7 or you've had one running successfully for two years, you're probably not looking to upgrade it. But if you have a five year old Drupal 6 site, you are, and we're coming back for you.
Core maintainer alexpott

At Prague we also started building consensus to overhaul the Drupal 8 release cycle to provide a better experience for businesses and developers alike.

Several core contributors discussing hard problems around a table with laptops
Prague sprint day
Photo credit: Amazee Labs

Milestone issues

  • #1497374: Entity storage
  • #1199946: Disabled modules status removed
  • #1605290: Entity render caching
  • #1203886: PHP module removed
  • #2083811: Field langcode handling uncrazified
  • #1983554: No more Entity BC-mode
  • #731724: Comments converted to a field that works with any entity type, after a year of epic work.

October 2013

After the swell of development from DrupalCon, October was also the month with more critical issues fixed than any other month of the 8.x cycle!

BADCamp

Numerous sprinters at BADCamp.
BADCamp pre-sprint
Photo credit: Amazee Labs

Drupal 8 Landing page

Milestone issues

  • #2106709: Router BC layer removed
  • #1851414: Views converted to accessible modals
  • #2023563: Entity field types converted to the new field type plugin
  • .

November 2013

November saw the passing of a dearly beloved old friend, the Overlay module. In its place is a nice "Back to site" link in the admin UI which will return you to where you were on the front-end. All of the usability, far less JavaScript! :D

Overlay module, RIP.

Milestone issues

  • #1952394: Configuration translation UI

    With Content + Config Translation in core D8 core is more translatable than D7 with all of contrib. #drupal

    — Tobias Stöckler (@tstoeckler) November 18, 2013

  • #1498574: Decision made to require PHP 5.4
  • #2055853: Revamped Block UI
  • #2088121: Removed overlay
  • #1886448: Theme registry service
  • #2125717: First Migrate in core patch lands
  • #2047229: Entity field and data definitions become classed objects, significantly improving Entity & Field API DX

December 2013

Milestone issues

And now, onto 2014!

2013 was an amazing year, but now it's time to turn our sights to 2014. We've finally turned the corner on attacking our technical debt, and are making steady progress on beta release-blocking issues which, if current trends continue, could result in a beta release as early as March.

A graph of critical issues over time, showing a huge explosion in 2013 that is starting to taper off since September.

Oct 30 2013
Oct 30

What's new with Drupal 8?

Greetings! We took a week off last week to attend BADCamp. There was sprinting-o-plenty, as well as tons of sessions on Drupal 8.

Numerous sprinters at BADCamp.

In the meantime, a lovely new Drupal 8 landing page has launched, which includes a list of major new features, information about the current state of the release, and a nice, big, green, demo button!

New Drupal 8 landing page

And speaking of Drupal.org, don't forget to get your patches downloaded in advance of the Drupal.org D7 launch, when d.o will be down for 24 hours. Please take the opportunity to go outdoors in the sun and otherwise step away from the computer. :)

Notable Commits

The best of git log --since "2 weeks ago" --pretty=oneline (121 commits in total):

Drupal 8 Around the Interwebs

Blog posts about Drupal 8 and how much it's going to rock your face.

Drupal 8 in "Real Life

Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Oct 08 2013
Oct 08

Just a general heads-up that we plan to roll D8 alpha 4 on Friday, October 18, both since it's been awhile, and also in order to have something stable to port modules from during the various sprints/sessions at BADCamp.

Now's a good time to wrap up anything you've got in progress that's pretty close, so we can show the world a new and improved D8 since alpha 3 at the beginning of September! :)

Aug 02 2013
Aug 02

I've seen some Drupal module developers out there have a lot of trepidation about moving to Drupal 8, most often via hearsay from others or via occasionally dipping in to look around and being spooked by newfangeldy stuff like namespaces, object-oriented code, and weird directory structures.

Alex Bronstein, long-time core developer and first-time blogger ;), has written an excellent piece offering a small introduction to changes to Drupal 8 for people who are less familiar with modern PHP and more familiar with traditional Drupal code, on what to expect, how to map your current knowledge to the new paradigms, and some of the rationale for these changes and why they're a good thing for Drupal.

You can read it here: http://effulgentsia.drupalgardens.com/content/drupal-8-hello-oop-hello-w...

Aug 02 2013
Aug 02

I've seen some Drupal module developers out there have a lot of trepidation about moving to Drupal 8, most often via hearsay from others or via occasionally dipping in to look around and being spooked by newfangeldy stuff like namespaces, object-oriented code, and weird directory structures.

Alex Bronstein, long-time core developer and first-time blogger ;), has written an excellent piece offering a small introduction to changes to Drupal 8 for people who are less familiar with modern PHP and more familiar with traditional Drupal code, on what to expect, how to map your current knowledge to the new paradigms, and some of the rationale for these changes and why they're a good thing for Drupal.

You can read it here: http://effulgentsia.drupalgardens.com/content/drupal-8-hello-oop-hello-w...

Apr 29 2013
Apr 29

(Sorry for spamming Drupal Planet with this, but a few people on IRC were saying it might be a good idea for people to get a wider heads-up, given the number of Drupal community hats I wear.)

In a week, we're heading down to Minnesota to pick up our new addition to the family, and so starting May 6 I'll be on maternity leave for 3 months, until ~August 1 (thank you, Acquia!!).

Here's an outline of how that may or may not affect you, and who to talk to instead:

  • For Drupal core commits, the wonderful Alex Pott has been brought on board, and is doing a great job of mowing down RTBC patches. I'm sure I'll still be poking around in the queues myself from time to time, as well, as goodness only knows what Drupal 8 could turn into by August. :D
  • For more "meta" D8 stuff, as well as general Drupal community-related topics not covered below, reach out to the fabulous xjm, who is holding down the fort on that side of things.
  • On the Spark engineering management side of things, the lovely Gábor Hojtsy is holding the reins.
  • For Drupal Association stuff, the marvelous Donna Benjamin will handle Secretarial duties during board meetings, and Tatiana has been doing a great job keeping the community appraised on d.o upgrade process.
  • On the Drupal[.org] governance side of things, I still have some outstanding todos, which I'm going to try and finish up this week. Dries is the main point of contact about this going forward.
  • On Google Summer of Code-related matters, Cary Gordon is leading a BoF discussion at DrupalCon Portland on how to better gear up for next year.
  • Speaking of DrupalCon Portland, I unfortunately won't be attending, so please have double the fun for me, ok? :D

Whew! I think that's everything. :) See you all on the other side of parenthood! EEEEE!

Apr 29 2013
Apr 29

(Sorry for spamming Drupal Planet with this, but a few people on IRC were saying it might be a good idea for people to get a wider heads-up, given the number of Drupal community hats I wear.)

In a week, we're heading down to Minnesota to pick up our new addition to the family, and so starting May 6 I'll be on maternity leave for 3 months, until ~August 1 (thank you, Acquia!!).

Here's an outline of how that may or may not affect you, and who to talk to instead:

  • For Drupal core commits, the wonderful Alex Pott has been brought on board, and is doing a great job of mowing down RTBC patches. I'm sure I'll still be poking around in the queues myself from time to time, as well, as goodness only knows what Drupal 8 could turn into by August. :D
  • For more "meta" D8 stuff, as well as general Drupal community-related topics not covered below, reach out to the fabulous xjm, who is holding down the fort on that side of things.
  • On the Spark engineering management side of things, the lovely Gábor Hojtsy is holding the reins.
  • For Drupal Association stuff, the marvelous Donna Benjamin will handle Secretarial duties during board meetings, and Tatiana has been doing a great job keeping the community appraised on d.o upgrade process.
  • On the Drupal[.org] governance side of things, I still have some outstanding todos, which I'm going to try and finish up this week. Dries is the main point of contact about this going forward.
  • On Google Summer of Code-related matters, Cary Gordon is leading a BoF discussion at DrupalCon Portland on how to better gear up for next year.
  • Speaking of DrupalCon Portland, I unfortunately won't be attending, so please have double the fun for me, ok? :D

Whew! I think that's everything. :) See you all on the other side of parenthood! EEEEE!

Feb 08 2013
Feb 08

As Gábor pointed out, now's the time to help make Drupal 8 more unified and user/developer friendly. A great way to do that is try porting your modules, now, while there's still time to fix the APIs before code freeze.

Here's the video and slides from my Upgrading your modules to Drupal 8 talk at DrupalCon Sydney 2013, featuring the Pants module.

[embedded content]

Slides: PDF | PPT | KEY (the canonical version)

But wait, there's more! ;)

The DrupalCon talk was only an hour, so wasn't nearly long enough to walk through the actual steps involved in each API. However! Thanks to the magic of Git (and particularly git rebase -i ;)), you can actually step through each step in the porting process.


$ git clone --recursive --branch 7.x-1.x http://git.drupal.org/project/pants.git

This will get you the 7.x version of the Pants module so you can look at code that hopefully looks somewhat familiar. :)

From there, you can step through each of the steps as follows:


$ git branch -a
* 7.x-1.x
8.x-01-basics
8.x-02-tests
8.x-03-config
8.x-04-blocks
8.x-05-router
8.x-06-twig
8.x-1.x

$ git checkout 8.x-01-basics
$ git log

Note: Each commit message cross-references the change notification for that particular issue. (They're more granular at the beginning than at the end; sorry. :\)

There's also kind of a "brain-dump" of notes if you want to present these at your local user group: http://drupal.org/node/1911346

Note: This is accurate now, but not necessarily tomorrow or especially not next week. ;) Nevertheless, I hope this is able to help someone out there get involved in Drupal core! :) There's a global sprint happening tomorrow!

Feb 08 2013
Feb 08

As Gábor pointed out, now's the time to help make Drupal 8 more unified and user/developer friendly. A great way to do that is try porting your modules, now, while there's still time to fix the APIs before code freeze.

Here's the video and slides from my Upgrading your modules to Drupal 8 talk at DrupalCon Sydney 2013, featuring the Pants module.

[embedded content]

Slides: PDF | PPT | KEY (the canonical version)

But wait, there's more! ;)

The DrupalCon talk was only an hour, so wasn't nearly long enough to walk through the actual steps involved in each API. However! Thanks to the magic of Git (and particularly git rebase -i ;)), you can actually step through each step in the porting process.


$ git clone --recursive --branch 7.x-1.x http://git.drupal.org/project/pants.git

This will get you the 7.x version of the Pants module so you can look at code that hopefully looks somewhat familiar. :)

From there, you can step through each of the steps as follows:


$ git branch -a
* 7.x-1.x
8.x-01-basics
8.x-02-tests
8.x-03-config
8.x-04-blocks
8.x-05-router
8.x-06-twig
8.x-1.x

$ git checkout 8.x-01-basics
$ git log

Note: Each commit message cross-references the change notification for that particular issue. (They're more granular at the beginning than at the end; sorry. :\)

There's also kind of a "brain-dump" of notes if you want to present these at your local user group: http://drupal.org/node/1911346

Note: This is accurate now, but not necessarily tomorrow or especially not next week. ;) Nevertheless, I hope this is able to help someone out there get involved in Drupal core! :) There's a global sprint happening tomorrow!

Feb 04 2013
Feb 04

This was originally posted to the "The influence of subtlety" thread on the Drupalchix group back in 2010, but since that was awhile ago now, and since I'm giving a talk on How to Create Ravenously Passionate Contributors at DrupalCon Sydney (and this experience played a huge part) I figured I'd post this to Drupal Planet as well.

Here are some highlights from my first DrupalCon (Vancouver, 2006).

For context, to those who didn't know me back then, imagine the most introverted, shyest, mousiest little geek you can imagine, whose big ice breaker plan was to put on a Google Summer of Code shirt and tuck herself into a corner in the lounge of the hotel everyone was staying at, hoping desperately that someone would maybe, possibly recognize her and come talk to her, since she was too shy to actually introduce herself to anyone. ;) That was me, 4.5 7 years ago. My interactions at my first DrupalCon had a *huge* impact on the future direction of my life.

  • Inclusiveness: Adrian Rossouw, Drupal mad scientist extraordinaire, was talking super excitedly about crazy next-generation Form API stuff and I was sitting there nodding vaguely, kind of deer in the headlights about it. He paused and said basically, "Oh, sorry. Did that not make sense? Here, let me try explaining it a different way, because it's REALLY AWESOME and I want you to be as excited about it as I am." And then proceeded to do so, and I was. :)

    Note that he didn't end the conversation and then go off and talk to someone else more at his level, nor did he ask me if I was in the wrong room, implying I wasn't smart enough to be part of this interesting conversation. Instead he saw me as an equal who just needed to get brought up to speed, and made a conscious effort to include me in the discussion.

  • Role models: Though there were other women at that Drupalcon who I bonded with, I remember being particularly drawn to Allie Micka, because she was hardcore. She is a total geek (meant in the most complimentary way!), runs her own hosting company, can rattle off random unix sysadmin facts like nobody's business, and at Drupalcon she was leading or co-leading talks on brain-blowing stuff like relationships API. And the guys respected her. When she talked about why a certain approach was good or bad, they'd sit back and listen, and took her seriously.

    While I wasn't *remotely* at Allie's level (and still am not now, and never will be :)), I saw someone I could relate to, and received confirmation that if someone like that was at home in this community, there was a place for me, too.

    This is why all types of diversity initiatives in our community are really important. We want people from all walks of life, backgrounds, interests, skill levels, etc. to see someone they can relate to kicking ass in our community in an environment of mutual respect.

  • Challenges: One evening we were all seated around a big long table in one of the hotel's conference rooms, Moshe at the helm, handing out release-blocker bugs for the folks there to look at so we could get Drupal 4.7 out the door (deja vu, anyone? ;)). I wanted to help, but wasn't sure where to start. Moshe fired me off a couple of bugs to look into. One was way over my head, and I told him so, but he told me to stick with it and do what I could, asking for help if I needed it. I started with a basic code review, but it actually revealed a deeper bug, which would've led to further regressions had it not been cleaned up. It was a little thing, but I felt a profound sense of accomplishment for making some tiny little contribution to helping 4.7 come out faster.

    I hope that we can retain this same "spirit" in code sprints today, even though there are several hundred rather than a dozen or so people around the "table". It's invaluable for communicating the Drupal community's "spirit" of contributing, and getting people hooked. :)

  • Encouragement: At lunch with Allie, Earl, and some other folks, we were talking about what sessions we wanted to attend, and I told everyone I was planning on attending the module development tutorial for newbies. I got some chuckles in return, saying "No, you seriously don't need to attend that session. You've been coding modules for 9 months now." It was a silly thing, but it opened my eyes to the fact that "oh, hey, maybe I *do* know something after all." :P~

    I see this come up a lot at the Drupalchix BoFs. A woman will introduce herself as "not a coder" and then go on to detail all of the very-much-code-related things she does: theming, front-end development, putting together code snippets from the repository into something that works, etc. With some encouragement, I think there'd be far less devaluing of skills all around, and more people taking big leaps they hadn't taken before.

The subtlety in these interactions was key. If any one of those instances had gone differently (had, for example, the guys rolled their eyes at Allie when she attempted to explain her approach towards relationship API, or had I been politely asked to leave when I joined the core bug squashing sprint and didn't know anything), I don't know the effect it would've had. But I do know that together, they formed the perfect concoction for getting me totally hooked on the Drupal community and sticking around long-term. :)

I think we can do a lot to off-set this trend by changing some of our default assumptions:

  • Assume that the next person you interact with could become the next $prolific_contributor if only they were given the right guidance.
  • Assume that people at DrupalCons belong, unless they've told you otherwise, or have explicitly asked for help.
  • Assume that someone who starts out their interactions with the community in a blundering fashion could become totally engaged and one of your biggest assets, if they're only shown "the Drupal way".

And most of all, if you see someone mousy and shy, hiding in the corner at Drupalcon who doesn't have anyone to talk to, go talk to 'em. You might just change their life. :)

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web