Overlap with / duplication of Deploy module

Even though I'm not a committer, I'd like to comment on this.

Correct me if I'm wrong, but Deploy is targeted at Services-style push deployment of content. Deploy is suitable for conceptually connected Drupal systems.

I agree that UUID Features is similar in its usage of UUID and installation/update of deployed content. Nevertheless, UUID Features is targeted at a different scenario, where network connection between the two sites are not THE means to deploy content. Also, where sites running Deploy tends to manage distributed content from the hub, UUID Features follows the Features paradigm, managing content as components of a module to deploy in a use case (see Kit Feature Specification). One can also set up a Feature Server to broadcast update notifications. Lastly, Services is great, but is undergoing some major development for version 3. I would tend to wait since I need Views 3, which doesn't agree with Services 2.

My point: they are for different use cases.

After another look at the Deploy code, I think I understand more of what you are getting at. Without overtly assessing the Deploy module, I think that despite its various implementations of content import/export, the fact that deploy_send is woven into each deploy module deters people from using it as a basic (i.e. copying-and-pasting files) content migration API.

Also, the issues you raised are better targeted at the Features module, which actually implements import/export for other modules, such as Views and Imagecache. UUID Features was meant to be a direct integration of UUID with Features. Also, Features was meant to be "defaults" implementations, meaning individual instances override basic settings, although I'm not sure whether UUID Features forcibly updates existing objects wherever exported objects are deployed.

I appreciate the architecture of Deploy. I can see how other modules can, for example, implement hook_node_deploy in much the same way as feature customizations implement hook_COMPONENT_alter to augment features exported by some module. Unfortunately, if I understand your code correctly, the hook_deploy is tasked with exporting content directly to remote servers. Perhaps somewhere down the line you could collaborate in some form of import/export API (like there was back in D5) to expose the content preparation and assimilation process so that Deploy and UUID Features can both use a common underlying API.

Again, I'd like to emphasize that Features is mainly used to generate code that implements defaults hooks, and so follows UUID Features. The objects prepared by Deploy are meant to be injected into the existing workflow of a deployed site; therefore the data structure may not be exactly compatible with objects that are meant to be a default set up from a feature.

However, if I've simply missed a crucial piece of your code and you'd already addressed the issues I mentioned, then I stand corrected.

I have been working with a variety of different solutions for trying to manage the configuration and content management issues surrounding Drupal. I examined copilot, features, patterns, deploy, and several others.

What I would like to point out is there isn't one size fits all. There are different situations that call for different solutions. For example deploy seems excellent at staging changes for large sites with multiple people and by hand configurations in production isn't going to fly. Where as features is a great way to create prebuilt sites that contain a lot of functionality out of the box (ie. open atrium and managing news). I for one was trilled when I found uuid and uuid_features. It added that last bit of crucial functionality to be able to produce a prebuilt site containing content as well.

I would also like to note that of all the types of solutions to solve this complexity, the developmentseed guys are the only ones that stepped up and released their code. Versus all the other solutions sitting in dev. That isn't a shot at anyone, but features have about 18000+ sites using it atm.

If deploy wants to extract their UUID functionality so both deploy and uuid_features can depend on the same functionality that is cool by me. But this module is crucial to our process and I can see it being vital for a long time.