I've already sent this stuff around.  Writing it up as an RFC:

In the next iteration Image Factory aim to make significant improvements and changes to its underlying model and its API. These changes will remove any conductor specific content from image factory altogether.  See: and

In order to allow conductor API implementation and new imagefactory API integration to work in parallel we will we can implement image management functionality as a rails engine:

Using an engine for the integration gives us other benefits such as a standalone UI for factory and also a pluggable engine that can be used in other rails applications.  It keeps a loose coupling between conductor and factory.  Which means there should be minimal disruption to conductor on major releases of factory and the image management back end service (factory) could be swapped in/out if we ever needed to do it.

The engine itself similar to a rails application which supplies all the controllers, views, routes and generators for creating image factory models. A prototype can be found here:

The prototype includes generators for creating the image management models, controllers and views for managing CRUD operations on the models and also the routes. Under the test folder is a dummy app that shows how this engine could be integrated with conductor. Showing a simple example on how to extend the engine models.

The testing structure should consist of integration tests as well as unit/behaviour.  enginex (the tool that creates the skeleton engine - now included in rails >3.1) creates an integration set test environment using the dummy application.  I suggest we stick to the testing structure already in place in the prototype.  However, we should use RSpec as the testing framework for consistency.

We also have a feature page that outlines the expected behaviour here:


Hi all,

We have a wiki page or two talking about using git, but one is fairly
out of date (it, for example, warns that you shouldn't ever push to
master). Another one was written by me some time ago, and needs some

What I'd really like is to write up some super-clear documentation
allowing those new to the project and/or git to get up to speed pretty
quickly. I'd like to send some draft content here, based on my workflow.
But I was hoping for feedback on it, both in terms of technical
suggestions and advice on wording/ordering/etc.

For setup, I'd like to recycle some of the content from
(but without the erratic indentation that exists today).

For normal workflow, I think something like the following:

1.) Update master, with "git pull master".

2.) Check out a local topic branch for your work, with "git checkout -b

3.) Do your work, commit your changes to your branch. (Maybe a section
on "git add", "git commit" practices, etc.)

4.) With your changes committed on your branch, rebase against master to
pull in any updates since you started -- "git rebase master" (I normally
run "git checkout master; git pull" first)

5.) Format your patches, with "git format-patch HEAD..master" (or the
500 different ways you can express something equivalent). Send them to
the list with git send-email.

6.) Do other work on other branches, perhaps, until you receive an ACK.

7.) Switch back to your branch (if needed), and rebase against master

8.) Switch to master, and run "git merge my_new_feature" to merge in
your changes.

9.) Push with "git push"

I'd also like to have a section on *applying* patches from the list, but
I'm not sure how other people do this. I create a topic branch from
master, and then use mutt to pipe the message body to "git am -s". How
do other people handle this?

-- Matt
I just want to jump in before this discussion gets too deep and let it
be known that I'm currently writing up a proposal for some pretty
drastic changes in our git/release workflow.  I don't have anything to
share yet; I want to make sure to thoroughly explain and justify why I
think it should work this way.  Hopefully tomorrow afternoon I'll have
my first draft up.

Carry on