On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews <everett.to...@rackspace.com> wrote:
> 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 > changes. > > For example, specifications with the APIImpact flag can be found with the > following query: > > > https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:apiimpact,n,z > > 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: https://wiki.openstack.org/wiki/CrossProjectLiaisons Isn't that enough? Regards Angus > Thanks, > Everett > > > _______________________________________________ > 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