Contact Information

Owner Aeolus Team
Contact: #aeolus or
Purpose Release Engineering Process
Related N/A


This SOP focuses on the Aeolus / CloudForms development process. It describes the schedule and process to make tags, create rpms, tarballs, and update our upstream release documentation.


Each sprint will have several key days. Sprints begin and end on Thursdays and are three weeks in length (although the following calendar shows days falling in each of four weeks for readability, the Sprint is three weeks long).

It's critical to meet deliverables on these dates and not slip items. We go from planning of new features to minor releases every three weeks and this pace requires a significant amount of discipline. Also, it means we must keep a focus on simplicity. If something can't be coded, tested and handle any migrations within 2 weeks, we are probably taking on too much. Simple, small, and extremely fast - that is our development model.

Required Git Repos

Currently the four components owned directly by the Aeolus team are

Additionally, we depend directly on the alchemy ui project

Deployment for development and testing are managed using the dev-tools project

Maintenance of RPM packaging artifacts

For each of the four main components (conductor, aeolus-configure, aeolus-cli, and aeolus-image-rubygem) care should be taken to maintain RPM specfiles, in particular the package dependencies (Requires, BuildRequires) must be updated when new dependencies are introduced to the codebase.

To facilitate packaging for RPM-based downstreams, each package should successfully build an RPM at the end of each Sprint. RPM packages can be created in a git checkout by issuing the following commands in each checkout's top directory:

Configuration of alchemy

Conductor has an RPM BuildRequires on the converge-ui-devel package. To build the converge-ui-devel RPM, check out alchemy (See previous section 'Required Git Repos') and run 'tito build --test --rpm' in the checkout.

Use of dev-tools for QE testing purposes

As noted previously, the dev-tools scripts are our primary means of providing QE with a consistent, easy-to-configure, multi-distro installation method for testing.

Organization of Upstream Releases