Posted by adrian on June 2, 2008 at 7:48pm
Start:
2008-06-06 23:00 - 2008-06-07 00:00 Etc/GMT-7 We have a weekly development meeting on #hm2 on irc.freenode.net, to discuss development, and make our weekly release.
If you are interested in hostmaster 2, please join us.
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2008&mont...
Comments
Actions from the last meeting
Those are the actions that were noted during the last irc meeting:
thanks for keeping us
thanks for keeping us informed here ... if drush needs changes for HM, please let me know. we want to support HM, our best customer :)
HM and deploy
There are lots of people interested in potentially using HM as part of the solution to dev/qa/prod -- and drush fits in here, too. The other piece is maybe deploy by heyrocker, which is new and doesn't currently use drush for anything.
I'd love to find some time to focus on JUST this issue...
Collaboration
Have any of the HM folks talked to heyrocker about collaborating? I was wondering about this project as well, how similar/different it is.
Yes
That would be me :P I talked to heyrocker about this -- he needed to get an initial version of deploy out the door. As Mack points out below, the overlap is likely in helping with dev/test/prod.
Hm and Deploy collaboration
Hi
I think that hostmaster might do something clever like pre-configuring the deploy module... The deploy module is focused on migrating configuration settings from site to site (like cck types, system settings, views and panels) and HM focuses on (as I understand it) the deployment and updating of the structural components of the sites, and provisioning for new sites.
Integrating the two would be great, would enable us to deploy a prod-stage-dev set of sites, preconfigured with deployment rules that the deployment module uses to manage its deployment sets. Exposing aspects of the deploy module to drush would pave the way for custom hostmaster behaviors.
One of the issues that heyrocker highlighted in his presentation in vancouver was that there is still not a good way to migrate nodes, which is a larger problem...
this is all very exciting stuff -M
That would essentially entail.
Writing 2 modules :
hosting_deploy - for all the front end integration needed.
provision_deploy - for setting up each of the individual client sites.
We should probably also be careful about how we let the deploy functionality shine through.
Perhaps through a 'configure' tab on each of the site nodes, instead of a central menu.
--
The future is so Bryght, I have to wear shades.