RandyFay.com

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.

Hello Drupal world! I wanted to let you all know about some exciting changes in our lives.

Many of you know that my wife Nancy and I have been long-term fans of the Nicaraguan water organization Agua Para La Vida (which means "Water for Life" in English). We visited this tiny organization on our bike trip through the Americas in 2008, and returned to refresh our relationship (and their website) in January of this year. APLV is very tiny NGO (non-governmental organization) that helps little communities in rural Nicaragua build their own clean drinking water and sanitation systems. Communities that have never had clean drinking water build their own gravity-flow water systems and it can transform their lives and health. APLV provides the technical expertise, leadership building, and of course the required material components of the system, and the community provides all the manual labor and then maintains the system for the long term.

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?

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.

Here is my description of Drupal's governance. I am certainly interested in your reaction to it in the comments:

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.

The fact that world-wide open source communities can organize themselves to collaborate is one of the great treasures of the world's recent history. If you're pessimistic about the world's future and about governance in general, you should really take some time to look at all these great open source projects and their incredible success. Drupal is an example right there with the Linux kernel project, Wikipedia, Debian, Ubuntu, KDE, and dozens of others. I think they give us great reason for optimism. The fact that communities like the Drupal community can thrive is a huge reason for optimism about the future!

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 of governance in preparation 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?.

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.

Why do organizations (and countries, and families) need good governance?

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.