Open Stack

My biggest concern with your proof of concept is that it would require
all outstanding blueprints to do a rebase, which sounds painful. Could
we perhaps create a subdirectory for novaclient, and keep the nova
stuff at the top level until most things have landed?

Michael

On Wed, Apr 23, 2014 at 10:24 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>
>
> On Tue, Apr 22, 2014 at 5:04 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>>
>> On Tue, 2014-04-22 at 17:00 -0700, Joe Gordon wrote:
>> > Hi All,
>> >
>> >
>> > Several folks have submitted python-novaclient blueprints to nova
>> > specs for the Juno Release [0][1], but since python-novaclient isn't
>> > part of the integrated release this doesn't really make sense.
>> > Furthermore the template we have has sections that make no sense for
>> > the client (such as 'REST API impact').
>> >
>> >
>> > So how should we handle python-novaclient blueprints? Keep them in
>> > nova-specs in a separate directory? Separate repo?
>> >
>> >
>> > I think generalize the nova-specs repo from a repo for blueprints for
>> > just nova to a repo for all 'compute program' blueprints. Right now
>> > that would just cover nova and python-novaclient, but may include
>> > other repositories in the future.
>
>
> Here is a proof of concept: https://review.openstack.org/#/c/89725/
>
>>
>>
>> +1
>>
>> -jay
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia