drupal

One of the things the Drupal Association struggles a lot with is the pricing of DrupalCon tickets for attendees. As detailed in the 2011 Annual Report (1.3 MB PDF), DrupalCon tickets make up a significant portion of the organizations' overall revenue, which goes to funding hugely important long-term projects like the Drupal.org redesign and Git migration, server upgrades, programs like the Community Cultivation Grants, as well as salaries for our staff to help run operations. While we are actively working on diversifying our revenue stream through initiatives like a revamped Drupal Marketplace and hosting listings, and adding numerous benefits to our membership program, the fact remains that in the meantime, DrupalCon ticket sales help to off-set significant costs for programs that help benefit the wider Drupal community, including those individuals who could never hope to attend a DrupalCon due to family/geographical/visa issues.

At the same time, we also recognize the wonderful diversity of people in our community. And for students, hobbyists, non-profits, evaluators, freelancers, and others, even the significantly off-set ticket prices (thanks to our generous DrupalCon sponsors) can make DrupalCon attendance prohibitive to the people we hope most can get there. And while we offer full-ride scholarships for a limited number of people in financial need, asking for one is often uncomfortable, especially by people who give a lot to Drupal already. In the past, we've done super-cheap "land grab" tickets (first 100 or so), but often those go to the people who don't need them: the major Drupal shops and others making ample money off Drupal who already know they'll be coming to DrupalCon, regardless of ticket cost.

This time around, we're doing something a little different. The Drupal Association has set aside a number of half-price tickets to students and non-profits, as well as FREE tickets to contributors. To snag one, you have to apply to lead a sprint on the final sprint day. These applications will get checked over by the same group who looks over the scholarship applications, and use similar criteria (involvement in community of the participant, impact of the sprint on larger project, etc.) to evaluate the submissions.

So, if you're someone who is driving important change in Drupal (or someone wants to!), please tell us about your plans and you could qualify for complimentary admission!

I did a fresh installation of Drupal 8 this morning and came across a bit of ugliness: an ugly grey border on the home page, caused by an empty div being inserted into the page:

My last fresh install of Drupal 8 was about a week ago and didn't have this problem. I didn't relish the idea of going through all of the commits since then one-by-one to figure out where this bug was introduced.

Enter the git bisect command! The git bisect command works by performing a "binary" search between one state of the code and the other in order to find, by process of elimination, where a given problem was introduced. It's quick, it's easy, and by golly it just works!

Here's how to use git bisect, step-by-step!

Some folks noticed that as of Wednesday's release, we went from 7.4 -> 7.7 and are a bit confused about what's going on, as well as why these releases happened in such rapid succession, so soon after the 7.4 release. Here's the skinny:

• As of Drupal 7.1/Drupal 6.21, Drupal core does monthly releases. This was a new policy the core team discussed and implemented back in May, which lays out a schedule of the last Wednesday of the month for new core releases.

  This policy change has helped tremendously to provide predicability for Drupal site maintainers so they don't need to fret every Wednesday about "what if" a new core release comes out, it's helped to ensure timely fixing of security issues, and also has encouraged a general "swarming" around bug fixes in a timely manner to ensure they make the next release deadline.

  The monthly rate will likely slow down as D7 continues to mature, but for now it's really helping to provide focus on working through some of the backlog and getting contributed module blockers unstuck.

• When security releases are required, we create two releases. One which has only the security patches, and one that has the security patches, plus all the bug fixes to date.

  Why do such a silly thing, you might ask? Because it's *really* important that security fixes get rolled out pronto, whereas the bug fix releases might conceivably need more testing to make sure they don't create any adverse effects in your environment. So we offer Drupal 7.5 for those who want only the quick fix, and Drupal 7.6 for the whole shebang.

  This graphic by Gábor Hojtsy, included on all release announcements, lays it out rather simply in flowchart form.

• Drupal 7.6 was accidentally rolled incorrectly, hence 7.7. The only difference between 7.7 and 7.6 is literally a one line fix to the VERSION number in bootstrap.inc (ok, fine, technically 3 lines because of CHANGELOG.txt ;P). I blame being holed up sick in a hotel room with a stomach flu for missing the git commit between vi bootstrap.inc and git tag. Sorry about that. :(

  Thankfully, some helpful friends are helping to work on some automation tools for the process so that doesn't happen again. :)

Hope that helps clarify things!

Back around the time of the Drupal 7 code freeze, Moshe Weitzman proposed the #D7CX (Drupal 7 Contrib Experience) movement. Developers were encouraged to add a #D7CX pledge to their project pages, indicating that they would port their contributed modules and themes to Drupal 7 by the time Drupal 7 was released.

Here is some data to measure the impact that this movement had, relative to Drupal 6, as well as some recommended next steps to help us complete the work that #D7CX started.