On Thu, Nov 13, 2014 at 4:45 AM, Angus Salkeld <asalk...@mirantis.com> wrote: > 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 thought that was what we decided in the Summit. So +1, that's a great idea. > > I see have added a new section here: > https://wiki.openstack.org/wiki/CrossProjectLiaisons > > Isn't that enough? Seems enough, at least to start with. Lucas > > 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev