drupal core diaries
This section is a bunch of tips and tricks for anyone who wants to work on core and see their patches committed faster. What works, what doesn't, and what REALLY doesn't. ;)
Ever use Drupal or Drupal.org and come across some kind of minor, annoying issue... say a typo, or a code comment that could stand to be improved, or some other change that's only a couple of lines of code... and you think to yourself, "Self, this would take you about 5 minutes to fix, but your to-do list is 43.4 km long. Pass."
Well, the next time that happens, please pause for a moment, and file an issue for that minor problem, and tag it as "Novice".
Thanks to the efforts of brand-new contributor demarcoz, we rolled out a new Drupal.org improvement this week: a link to the queue of all Novice issues on the Dashboard! (which was itself a Novice issue: http://drupal.org/node/1266380 :))
The goal of the "Novice" tag is to help identify "low-hanging fruit" issues. This way, people who haven't been using Git and rolling patches since they were in diapers can have something bite-sized to chew on while they work their way up the learning curve of setting up a development environment, figuring out quirky git commands, and finding their way around Drupal coding standards and API peculiarities. This is a much nicer introduction to contributing than showing them an issue queue with 50,000 issues in it and saying "There ya go! Pick one that sounds interesting!" :)
And while it might take a new contributor a few days to solve something you could solve in a few minutes:
a) It's really fun to walk new people through this process and see what sorts of things trip new people up.
b) They're now equipped to tackle even harder issues in the queue, and they can eventually help you with your own 43.4 km long todo list.
c) They can also help improve documentation in places where they got stuck, and even help mentor other novices!
So the next time you find a small issue you could solve yourself in a few minutes, please don't! Instead, tag it as "Novice" and help to usher in a new crop of eager new contributors. :)
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 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!
There is currently a lively, spirited debate about the forthcoming user experience changes for Drupal 7. A quick summary for those who have been unaware of this initiative: everyone (yes, especially you) needs to go to http://www.d7ux.org/ and actively participate in the discussion/brainstorming/wireframing/etc. in order to ensure that the end result is something we can all be proud of and meets our community's very diverse needs!
It's been interesting to watch the range of opinions expressed in the thread. On the one side you have people who have first-hand experience with how excruciatingly painful the learning curve can be for new users, either because they themselves had to wrestle for weeks about menus vs. taxonomy vs. nodes, or because they've spent time around others (co-workers, clients, spouses, etc.) and have watched them struggle. They're very excited about the prospect of some of these pervasive user experience issues being looked at in a very serious way. On the other side you have long-time members of the community, many of them prolific contributors, who are adept ninjas configuring Drupal sites. They don't want to see Drupal "dumbed down" to the lowest common denominator. In fact, the whole reason they initially chose and continue to stick with Drupal is the sheer power it places into their hands, and with great power comes a learning curve; it's to be expected.
At my "day job" at Lullabot, we've been hard at work on the Drupal UE (Usability Edition), which includes many fine improvements that I'd love to see make their way into Drupal 7. But what about our roots, the hardcore developers who eat, sleep, and breathe Drupal? Who is watching out for their interests?
In a fit of insomnia early this morning, I put together what I hope will be the start of a robust framework that optimizes Drupal's UX, but this time for the developer. I call it Better Admin module.
(Hey, neat! This was mentioned on ZDNet: Perfectionists need not apply.)
Most people in the free software community have probably read Eric S. Raymond's The Cathedral and the Bazaar, which compares and contrasts two free software development models: the Cathedral style (think, "perfectionism") and the Bazaar style (think, "chaos").
While Drupal itself is clearly an open, Bazaar-style project, many individuals in the Drupal community tend to take the perfectionist approach to development. After all, *thousands* of people will be using this code, and likely *hundreds* of developers carefully inspecting its inner-workings. How embarrassing would it be for another developer to stumble across a "no-brainer" bug in your code? Best to sit on things until you know it's really solid before putting it out there in front of people. Right?
Sure, that sounds logical. But in my experience, people who take this approach to development in an open source community, and especially the Drupal community, are at a severe disadvantage to those who embrace the chaos and put their changes out in front of everyone as they're going along, warts and all.
I'll attempt to illustrate this by way of a dramatization comparing the problem-solving approach of two hypothetical Drupal developers: Sloppy Sam, and Perfectionist Pat.
I would love to see a series of blog posts from Drupal developers on patch review strategies they employ, so we can share some tips and tricks and ramp up our collective review IQs. I'll start it off with mine. I call it "The 6-Pass Patch Review" (wittier names welcome! ;))
To begin, crack open your text editor. You'll use it to jot down notes and questions as you go through each of these passes. Other than that, no fancy tools are required to do most of this other than a keen set of eyes, an inquisitive mind, and the ability to empathize with people new to Drupal and put yourself in their shoes. (Of course, if you are relatively new to Drupal, then patch review can actually come easier for you than other people. :) Start today!)
As a standards zealot, one of the things I'd personally love to see happen in Drupal 7 is the eradication of table-based layouts. I'm giving stink-eye directly at you, Pushbutton, Chameleon, and Bluemarine. These themes are a strange abberation from the Drupal project's otherwise very meticulous attention to detail regarding web standards, and I'm quite positive that they directly contribute to the Drupal project's ongoing struggles to attract and retain visual designers. Garland is a huge step up, but it was never designed to be an easy to modify base theme, and unless designers happen to stumble across something like Zen, I imagine they come away thinking that Drupal's markup is ugly and antiquated and go to something a bit nicer out of the box like WordPress.
I want Drupal 7 to be an incredible release that ramps up the user experience by 1,000-fold, and making Drupal more accessible to designers and themers (along with an accompanying selection of great looking designs out of the box) is a huge part of that. Fortunately, I'm not alone!
In coordination with several prominent members of Drupal's design/theming community, including Joon Park, John Wilkins, Brad Bowman, Stephanie Pakrul, and Earl Miles, we've come up with what we think is a workable plan for accomplishing these goals.
The overall gist is:
- Replace Drupal's default markup with a flexible, standards-based framework that's easy to extend.
- Hold a theming contest which uses the base markup, and select the best N designs to go into core as sub-themes.
- Remove the old, crufty themes and replace them with the new, gorgeous ones.
So if you either a) are a web standards zealot who wants to lend your expertise to the discussion on selecting the default markup, or b) have some time / energy / etc. to help organize a theming contest, please coordinate over at http://groups.drupal.org/node/16200!
Today was the first day of my vacation (linking to Wikipedia in case you, like me, were not sure what this word meant) so naturally a bunch of us spent the entire day in #drupal slashing through bugs and features in preparation of DRUPAL-7-0-UNSTABLE-2 which should be tagged tomorrow, with lots of nice goodies. :)
As of this writing, there are over 5,600 active issues in the Drupal core queue. About half of those are listed in the 2,650 active issues for Drupal 7. And the "patch queue for Drupal 7 -- those issues that have at least *some* code to fix them in various stages of completion -- clocks in at 1,040 issues.
These numbers are, quite frankly, staggering. Discouraging, even, some might say. With so many issues out there vying for attention, how are we to find those ones that are really important, such as killer new features, powerful API enhancements, and critical bug fixes? While Drupal 7's development cycle doesn't have an expiration date on it yet, we all know that day will come, and probably sooner than we'd ideally like. What can we do to make sure that important patches are raised to the surface and receive adequate developer and committer attention?
To succeed, we'll need to employ a two-pronged approach: taking out the trash, and digging up the treasure.
Here's another tip for those who are looking for more reviews of their patches and faster commits: describe what the heck your patch does! :)
A simple enough premise, and It sounds obvious, right? But you'd be surprised how few patches are accompanied by a good, solid list of changes.