Starting in 6.x-2.x, we included an aegir contrib module (Hosting Platform Pathauto) in our makefile, and thus the Aegir distribution. I think that particular module should just be integrated into Hosting, since it's really pretty simple. But there are some fairly major sub-systems out in contrib right now that should perhaps be included in the same way. I have in mind particularly:

Most of these have Provision extensions too, so that'd have to be taken into account...

These are all pretty stable, and used in production at most of the lead development shops. In addition, the Aegir core maintainers are also maintainers of most of these extensions anyway. Further usage, and thus bug-fixing (and the usual Free Software virtuous cycle) should stabilize them even more.

So why not just merge those projects under Aegir itself? Well, it'd essentially cut off non-core maintainers from helping to maintain these sub-systems. In fact, I think we should really consider spinning off a number of other components in a similar fashion. I'd suggest the following:

  • quotas
  • dns
  • cron_queue (essentially deprecated)
  • signup form

The idea would be to re-include them by default, but spinning them off as separate projects would allow additional contributors to participate in maintaining them. I believe this would be a good way to on-board potential core maintainers.

Comments

helmo’s picture

+1 for adding more modules to the distribution...

Other candidates are (parts of ) Hosting site Git and Hosting platform Git.
But maybe that should just be merged to e.g. hosting_git

Also +1 for spinning off the mentioned modules. We could publish something about seeking co-maintainers for these.
E.g. via the announce mailinglist.

cweagans’s picture

Personally, I think hosting_platform_git and provision_platform_git should just be merged into Aegir core. It's not a lot of code (especially if it's built in), and it's useful to pretty much anyone.

helmo’s picture

ergonlogic’s picture

One difficulty this raises is that we'll also need to download the back-end components of these modules too. The last time I checked, there wasn't a Drush Make equivalent for Drush extensions, but if anyone has heard differently, please post a link.

One option might be to allow hosting features to declare the Drush extensions they require. Then, when we verify the hostmaster site to register enabled features, we could also download these extensions and run a 'drush cc drush'.

Other ideas?

helmo’s picture

I've also been thinking about managing Drush dependencies ... and opened #2224411: Declare dependencies on Drush modules to continue the discussion.

helmo’s picture

Issue summary: View changes
ergonlogic’s picture

ergonlogic’s picture

Issue tags: +Aegir 3.0.0, +Aegir 3.1.x

We need to determine what's going into our initial Aegir 3.0.0 release, and what'll come later in a point release.

ergonlogic’s picture

I added the proposed modules to the drupal-org makefile. They're commented out for the moment, but as their 7.x-3.x branches stabilize (or are created in a couple cases) we should start including them in builds. I also added a new aegir_tour module based on bootstrap_tour.

btopro’s picture

re AEgir tour / bootstrap -- we should keep an eye on http://walkhub.net. They use selenium tests to generate / play their tours and in talking to the founder, they are interested in having drupal distributions be able to use the service for free. Can do auto generated screengrabs for documentation and potentially make their creation more social instead of exportable / code maintainable. Just a thought (who knows it could go no where) -- made a demo today quickly http://walkhub.net/content/elmsln-test

gboudrias’s picture

Since Aegir3 is already out, maybe we should mark this as fixed and open individual issues for additional modules we want to add in the future?

Aegir3 already has hosting_tasks_extra, hosting_remote_import, hosting_site_backup_manager and hosting_git.

ergonlogic’s picture

Status: Active » Fixed

agreed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.