Gents,
I've already sent this stuff around. Writing it up as an RFC:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Image_Manageme...
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:https://www.aeolusproject.org/redmine/projects/image-factory/wiki/V2_...
andhttps://www.aeolusproject.org/redmine/projects/aeolus/wiki/Imagefactor...
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:
http://guides.rubyonrails.org/engines.html
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: git(a)github.com
<mailto:git@github.com>:aeolus-incubator/image-management-engine.git
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:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/V2_Conducot_AP...
Regards
Martyn
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
changing.
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
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Git_Workflow
(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
my_new_feature"
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
again.
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