This is the second installment of the communiqué highlighting some of the news from the Aegir community. In case you didn't catch the first issue, you can find it over here. Also, I've no doubt missed a number of interesting items, so feel free to write to me, so that I can include them in the next issue.

1. Core team changes

I'm very pleased to welcome two new co-maintainers to the Aegir core team: Jon Pugh and Cameron Eagans. Also, Miguel Jacq and Steven Jones have been granted the title of "Maintainer Emeritus".

After discussions at NYCcamp, Jon Pugh, the creator of DevShop, agreed to join the Aegir maintainers team. Among other things, Jon has a wealth of experience with Git-based workflows, and is the only contributor I'm aware of to have introduced a new context-type (environments) into Aegir. At DrupalCon Austin, Cameron Eagans also agreed to join the Aegir core team. I believe that Cameron has worked more on Drupal core issues than all the other Aegir maintainers combined. Their broad experience and proven expertise with Aegir's architecture, make Jon and Cameron invaluable additions to the team.

Once again, welcome to the team, Jon and Cameron!

At the same time, a couple Aegir veterans, Miguel Jacq and Steven Jones, have both communicated to me that they are no longer in a position to actively participate in the Aegir project. Out of respect for their significant contributions to Aegir, and in the hope that we can tempt them back to more active roles, they'll continue to have full maintainer privileges. However, in recognition of their reduced participation, they won't be actively solicited in project decision-making.

Thank you, Miguel and Steven, for all your efforts towards making Aegir the wonderful project that it is, as well as your patient mentoring of newer contributors and maintainers.

2. DrupalCon

DrupalCon is always a great opportunity to strengthen relationships built online by putting faces and voices to drupal.org and IRC usernames. DrupalCon Austin was no exception. The Aegir community was well-represented, including Brian Gilbert (realityloop), who made it all the way from Australia to help with Drupal core mentoring and sprints. I was also very pleased (and surprised) to meet up with Steven Jones, whom I hadn't seen since DrupalCon Munich, and who had travelled from the UK.

While there weren't any Aegir-specific sessions being presented, interest in the project is stronger than ever, as evidenced by two very well-attended BoFs. Jon pulled some strings to have the DevShop BoF and the more general Aegir one follow each other. So we had time for in-depth discussions of Aegir's architecture, suggested workflows and roadmap.

Jon also moderated a BoF entitled "The Great Multi-site Debate", to which I had also been invited to participate. The result was both interesting and entertaining. We broadcasted it live on YouTube, and thus have an archive of the event, which I strongly encourage everyone to check out: https://www.youtube.com/watch?v=9dJxEUM2YOY. There's even talk of a redux in Amsterdam.

For me, the highlight of every DrupalCon is always the Friday sprint. We had a chance to hash out a number of roadmap issues, which was great! This was the first event that I can recall where 4 Aegir maintainers were present at once. We were joined by contributors both from Drupal shops, and larger institutional users, such as a sysadmin from a major university, who was interested in maintaining RPM packages for Aegir.

With the end of DC Austin, we began planning for DC Amsterdam coming up at the end of September. The Aegir core team submitted 4 sessions, and I'm very pleased to see that another 6 sessions mentioning Aegir were also submitted: https://amsterdam2014.drupal.org/sessions/proposed?field_experience_valu.... Hopefully, some of these will be accepted, and we'll all have a chance to meet up again soon.

3. Documentation initiative

In the last issue, I announced our intention to refresh the Aegir Project's web presence: http://community.aegirproject.org/discuss/aegir-dispatch-issue-1#Refresh.... The most important component, in my opinion, is the move to readthedocs.org for our documentation. The very beginning of this effort can be found at http://docs.aegirproject.org.

While we've put quite a bit of effort into the wiki on http://aegirproject.org/handbook, it's less than ideal for our purposes. ReadTheDocs allows for a git-based workflow, simple, readable text files (in reStructuredText), as well as the ability to maintain local and/or forked copies and different branches matching our major versions. The source for the documentation is available at https://github.com/aegir-project/documentation.

Bear in mind that the effort to transition our documentation has only just begun. The initial setup is done, and some basic installation instructions and system requirements have been added. The next steps should probably be to add some help for how to contribute (basically just a pull request), and move the rest of the installation instructions.

Allowing easier contribution to the documentation from Aegir's user community was a major motivation for this move. If you're interested in helping out, feel free to contact any of the project maintainers (http://community.aegirproject.org/maintainers) for help getting up-to-speed.

4. Aegir 3

The development of Aegir 3 is progressing nicely. The Drupal 7 upgrade is essentially complete, and most core functionality is working as expected. Additional bug fixes are being merged regularly, and are mostly just API changes with the transition from Drupal 6. Some notable new features have been added recently as well, including:

• Server entity CRUD: While Aegir has been able to register servers and services for a long time now, there hadn't previously been a simple and safe way to remove a server form the system. This has largely been fixed, but ongoing work is still being tracked in https://www.drupal.org/node/2040445.
• Drush 7 support: Some changes to Drush's development branch had broken Aegir in a couple ways. First, Drush removed hook_drush_load(), which we used to ensure that backend code only ran when the corresponding front-end component was enabled. This was fixed in https://www.drupal.org/node/2191327, which allowed the use of Drush 7 with Aegir. However, we soon discovered a much deeper bug that blocked installation of Aegir on Drush 7: https://www.drupal.org/node/2281983. It turns out that this was a latent bug that had lurked in Drush for 3+ years, and was only activated by an otherwise harmless-seeming change. After half a morning of debugging, Antoine and I finally tracked down the offending code, and have written up a pull request for Drush to resolve it: https://github.com/drush-ops/drush/pull/684.
• We recently added a configuration option to allow setting the load threshold at which Aegir will back off from running further tasks. We'll be looking at adding a UI component to allow for this to be set from the front-end: https://www.drupal.org/node/2295923
• To enhance the documentation project, we've also begun work on a tour implementation to help improve in-line documentation: https://drupal.org/project/aegir_tour. This has highlighted some issues with lacking CSS identifiers. Fixing these will also make the UI easier to test. Further discussion can be followed here: https://www.drupal.org/node/2281067

There are a number of other interesting ideas and features being discussed and worked on. These include adding a new basic vhost-only site entity, a new Bootstrap-based theme, and a local local Vagrant project with Avahi-based automatic DNS resolution. More on these in the next issue.