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.gord...@gmail.com> wrote: > > > > On Tue, Apr 22, 2014 at 5:04 PM, Jay Pipes <jaypi...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Rackspace Australia _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev