Brainstorming tasks for next sprint

Jason Guiditta jguiditt at redhat.com
Tue Feb 14 15:21:03 UTC 2012


On 13/02/12 19:33 -0500, Wesley Hayutin wrote:
>
>I like your ideas, wanted to throw another out there..
>
>1. A scripted development environment.
>
>Why is it needed?? We have a complex application that pulls in resources from several different sources.
>It would be cool IMHO if we had some certainty we're all looking at the same thing.  Should help with our collaboration, and with
>automated unit/cuke tests.
>
>Right now everything is very stable, but think back to a year ago when rubygem hell rule the earth.
>It would also be cool if we didn't have to install the product first as well, but not sure if that's possible.
>
>Thanks..
>

I have been thinking about something (I think) along similar lines.  I
have some beginnings of this in conductor/util (build-all and a git
pull script that is not yet pushed), and martyn had a 'get all aeolus
repos' script in his own repo, maybe he can respond here with the link
again, so we have it together.  My thought was to split out util into
its own repo, and have it contain developer tooling, possibly in the
form of a gem and optional rpm (that part highly tbd).  A developer
wanting to work on the project would clone that single repo.  They
could then call the developer tool (working name is 'ad' to keep it
short, nemonic for 'aeolus developer') with something like:

$ ad fetch

This could then present the user with a list of aeolus repos
(preferably with short description, retrieved from github description)
and allow them to either get 'all', or check off/type numbers of the
repos they want to have a copy of. As they develop, fetch moves to
being used to keep their local copies of everything up to date (via
the flags shown below).

My initial idea is to keep the api for this tool similar to git and
aeolus, so there will be an undetermined number of commands, and
running ad [help,-h,--help] will return the list of commands.  Then
ad <command> [help,-h,--help] will return help for that specific
command.  An example of what fetch would tag for options is:

$ ad fetch [all|list] [repolist] [tag]


I suspect there are a number of things that could wind up in this
repo, but the idea is to keep them all focused on aiding development.
I think initial revs would focus on just 'fetch' and build' commands,
then we can expand it over time.

== Idea 2 ==

We have been using rake tasks of 'rpms' and 'yum' for configure, -cli,
and -image.  This code is currently duplicated in each project, which
drives me insane.  I'd like to get this extracted _somewhere_, whether
it be some upstream project (which I think Mo mentioned a while back),
or just a gem/rpm to make the task available system-wide.


== Idea 3 ==

Francesco and I have discussed adding a peer-level project/user on
github 'aeolus-incubator'.  This would be a home for any projects to
help around the aeolus ecosystem.  It may be extra tooling, pluggable
policy library, alternate expermiments for project management or bz
integration.  Basically anything that may be useful at some point, but
either is not close to ready yet, or we are not sure if it will even
be used.  Similar to apache, once a project is mature enough and has
community backing, it can be promoted to aeolusproject proper (and of
course, this means it gets picked up in the ad tool, which may also
get a flag to say 'get me incubator projects').

-j



More information about the aeolus-devel mailing list