[openstack-dev] [api] APIImpact flag for specs
asalkeld at mirantis.com
Thu Nov 13 04:45:18 UTC 2014
On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews <everett.toews at rackspace.com>
> Hi All,
> Chris Yeoh started the use of an APIImpact flag in commit messages for
> specs in Nova. It adds a requirement for an APIImpact flag in the commit
> message for a proposed spec if it proposes changes to the REST API. This
> will make it much easier for people such as the API Working Group who want
> to review API changes across OpenStack to find and review proposed API
> For example, specifications with the APIImpact flag can be found with the
> following query:
> Chris also proposed a similar change to many other projects and I did the
> rest. Here’s the complete list if you’d like to review them.
> Barbican: https://review.openstack.org/131617
> Ceilometer: https://review.openstack.org/131618
> Cinder: https://review.openstack.org/131620
> Designate: https://review.openstack.org/131621
> Glance: https://review.openstack.org/131622
> Heat: https://review.openstack.org/132338
> Ironic: https://review.openstack.org/132340
> Keystone: https://review.openstack.org/132303
> Neutron: https://review.openstack.org/131623
> Nova: https://review.openstack.org/#/c/129757
> Sahara: https://review.openstack.org/132341
> Swift: https://review.openstack.org/132342
> Trove: https://review.openstack.org/132346
> Zaqar: https://review.openstack.org/132348
> There are even more projects in stackforge that could use a similar
> change. If you know of a project in stackforge that would benefit from
> using an APIImapct flag in its specs, please propose the change and let us
> know here.
I seem to have missed this, I'll place my review comment here too.
I like the general idea of getting more consistent/better API. But, is
reviewing every spec across all projects just going to introduce a new non
scalable bottle neck into our work flow (given the increasing move away
from this approach: moving functional tests to projects, getting projects
to do more of their own docs, etc..). Wouldn't a better approach be to have
an API liaison in each project that can keep track of new guidelines and
catch potential problems?
I see have added a new section here:
Isn't that enough?
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev