Speaking of feature work reminds me - I think we also need to set up a sliiightly more
formal development process, with things like requirements and design.
I understand that we probably don't want to get excessively bogged down, but I could
see something lightweight still being extremely useful - something like requiring
developers starting a new feature (as opposed to a bug fix) to use a template to list the
requirements of the feature, as well as some high level design notes detailing how
it'll be done. Once it's ACK'd, the developer starts work, and assuming
there's an associated BZ, any patches done for the feature can easily be found.
This would increase both visibility and make it easier for others to support the code.
Mainn
----- Original Message -----
From: "Matt Wagner" <matt.wagner(a)redhat.com>
To: "Martyn Taylor" <mtaylor(a)redhat.com>
Cc: aeolus-devel(a)lists.fedorahosted.org
Sent: Tuesday, February 14, 2012 9:29:04 AM
Subject: Re: Brainstorming tasks for next sprint
On Tue, Feb 14, 2012 at 02:18:11PM +0000, Martyn Taylor wrote:
On 02/13/2012 09:06 PM, Matt Wagner wrote:
>b.) Smarter matching of where we launch instances. I don't think this
>will be something we get right the first time -- it seems like there are
>a bunch of criteria that different people will weigh differently. But I
>think that's all the more reason to start out with something now and
>iterate over it. Our 'priority' concept helps somewhat, but it still
>feels pretty constrained. It feels like we've worked to make it easy to
>launch an instance in the cloud of your choosing (a noble enough goal, I
>admit), as opposed to allowing you to launch an instance and let
>Conductor do something intelligent on its own.
I'd like to see some pluggable policy for this?
I think this is a good idea, both architecturally and as a way to get us
rolling. Then we can potentially start the ball rolling with a few
simple policies and expand from there.
-- Matt