RandyFay.com

Note that this documentation has been moved to http://drupal.org/node/1748596 and will be maintained there.

Since the Drupal.org testbots run on the OSUOSL Infrastructure you have to get through an authenticated proxy to access them. This article explains how to do that. The information will land on drupal.org when I can figure out a place for it.

First, you need a Supercell account. To get one:

Thanks to all of you for your enthusiastic and thoughtful participation in the Future of Drupal Governance core conversation at Drupalcon Denver. This post will provide resources for the conversation and attempt to summarize the ideas raised and actions taken at the core conversation, as well as to provide a path forward for us.

It's time to re-evaluate the strategy and goals of the Examples Project on Drupal.org.

The project had its origin as documentation examples, but they were buried in an obscure place in the CVS tree and had no executable format. During the D7 cycle we dusted them off, added tests, and put them into a maintainable place where they'd be automatically tested and were maintainable. Loads and loads of examples were added, and lots of things were improved. Lots of people put hundreds of hours into this, and the entire community appreciates it.

However, I think it's time to re-evaluate the maintenance of this project, and to talk about how it should be structured long-term. I personally am not committed to maintaining the new 8.x examples and changes that need to be made, and other maintainers have not been able to keep up either. The result is that testing on the 8.x branch has been broken (theming and render, contextual links) for nearly six months. And all that is before the real changes in 8.x core kick in.

This is the third in a series on governance and Drupal in preparation for the Drupalcon Denver Core Conversation on The Future of Drupal Governance. The first article discussed What is Governance and the second How Do Open Source Communities Govern Themselves?. Read all, Governance project on drupal.org, Drupalcon presentation video.

Drupal's governance structure is so lightly defined that when I searched for Drupal governance the primary article I found was this one on drupalmyths.com denying that Drupal's governance is poorly defined. Certainly nothing showed up on drupal.org. Of course, these things can use words other than the formal word "governance", but there really isn't much written about this topic.

This is the second in a series on governance and Drupal in preparation for the Drupalcon Denver Core Conversation on The Future of Drupal Governance. The initial article started off with What is Governance; Read all, Governance project on drupal.org, Drupalcon presentation video.

Just over a year ago I wrote a blog post explaining how to use git clone --reference to speed up git clones. That technique then went on to become a drush option (if $options['cache'] = TRUE and you're using git for drush downloads)

Well, I repent. git clone --reference should not be used IMO unless you really really understand three things:

1. You really need to speed up clones and other fetches.
2. You know that the cache directory will never be destroyed (.drush/cache/git in the case of drush managing the caching)
3. You will never copy your working directory some place it cannot reach the cache directory (like scp'ing it to a remote machine)

Unless you actually know #2 and #3, you can be really hurt. I know, I've done it to myself several times now.

This is the first of a set of blog posts on governance written for the Future of Drupal Governance core conversation at Drupalcon Denver - hope to see you there. The series continues with How Do Open Source Communities Organize Themselves?, Drupal Governance and The Future of Drupal Governance. (presentation video), (Governance project)

What is "governance?" Governance just a fancy word encompassing all the things we do to organize ourselves, make plans and decisions together, get things done, and resolve conflicts. It can be very loose (as is most of our governance in the Drupal community) or very structured. The key, of course, is whether it accomplishes what we want it to accomplish in the contexts we need it.

Git is so smart about merging that it's often possible to referesh a stale patch in the queue using just git, without even looking at the contents of the patch. (I'm not saying you shouldn't look at any patch you post, just that git will often do all the refeesh work for you.)

1. Update to the latest version of the project you're working with.
2. Use git log to find the hash of a commit near or just before the time the patch was posted.
3. Create a branch from that commit: git checkout -b <date_based_branch_name> <commit_hash>. (I often use the date for the branch name: git checkout -b aug10 <hash>
4. Apply the patch. It should apply cleanly unless there was already something wrong with it when it was created.
5. Use git add and git statusto make sure that all your changes are staged, then commit the results.
6. Create a new branch for the updated patch. I'll use git checkout -b bundles_removed_1245332_04 origin/8.x, which branches off of 8.x just for this feature branch.
7. Merge the date-based branch: git merge <date_branch>
8. If all goes well, you have a clean merge, and you can create a patch. In this case, git diff origin/8.x >drupal.bundle_warning_1245332_04.patch
9. If you still have a merge conflict, you probably only have the really relevant part of the conflict (changes actually made in your patch which conflict with changes which have been committed since the issue was last active.) In that case, you can use git mergetool to reconcile the differences, but that's for another session.

For just updating a patch that was obsoleted by the D8 core files move patch in November, see xjm's excellent, focused article.

Here's the screencast:

Webchick tweeted about favorite ways to capture the issue queue for long plane rides. I use the Scrapbook Plus Firefox addon.

Here's the quick screencast, followed by the recipe.

Using Scrapbook Plus to Capture the Drupal Issue Queue for Plane Rides from Randy Fay on Vimeo.

(There are screencasts illustrating these concepts at the bottom.)

I've been using git submodules for Drupal site deployment for quite awhile now, and I wanted to share my experience (for good and bad) with others who might be interested in using submodules (and to solicit comments from those who know how to do it better).

What are git submodules?

First "git submodules" have nothing to do with Drupal modules. They're a way of including one git repository inside another, in its entirety, and managing it from within the parent repository.

In a regular git repository, you have one .git directory in the root directory of the project that contains the entire history and all the revisions for that project. Every change in the project is tracked in that one .git repository.

Using git submodules you have one or more sub-repositories of the main one. They look exactly like a regular git repository, but the parent repository knows just enough about them to manipulate them.

For example, if we're using the regular Drupal checkout as our main repository and checking out Drupal modules as submodules, we might do this: