<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
On Nov 12, 2014, at 10:45 PM, Angus Salkeld <<a href="mailto:asalkeld@mirantis.com">asalkeld@mirantis.com</a>> wrote:<br>
<div><br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:everett.toews@rackspace.com" target="_blank">everett.toews@rackspace.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; position: static; z-index: auto;">
Hi All,<br>
<br>
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.<br>
<br>
For example, specifications with the APIImpact flag can be found with the following query:<br>
<br>
<a href="https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:apiimpact,n,z" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:apiimpact,n,z</a><br>
<br>
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.<br>
<br>
Barbican:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/131617" target="_blank">https://review.openstack.org/131617</a><br>
Ceilometer:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/131618" target="_blank">https://review.openstack.org/131618</a><br>
Cinder:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/131620" target="_blank">https://review.openstack.org/131620</a><br>
Designate:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/131621" target="_blank">https://review.openstack.org/131621</a><br>
Glance:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/131622" target="_blank">https://review.openstack.org/131622</a><br>
Heat:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/132338" target="_blank">https://review.openstack.org/132338</a><br>
Ironic:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/132340" target="_blank">https://review.openstack.org/132340</a><br>
Keystone:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/132303" target="_blank">https://review.openstack.org/132303</a><br>
Neutron:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/131623" target="_blank">https://review.openstack.org/131623</a><br>
Nova:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/#/c/129757" target="_blank">https://review.openstack.org/#/c/129757</a><br>
Sahara:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/132341" target="_blank">https://review.openstack.org/132341</a><br>
Swift:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/132342" target="_blank">https://review.openstack.org/132342</a><br>
Trove:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/132346" target="_blank">https://review.openstack.org/132346</a><br>
Zaqar:<span class="Apple-converted-space"> </span><a href="https://review.openstack.org/132348" target="_blank">https://review.openstack.org/132348</a><br>
<br>
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.<br>
<br>
</blockquote>
<div><br>
</div>
<div>I seem to have missed this, I'll place my review comment here too.<br>
<br>
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?<br>
</div>
<div><br>
</div>
<div>I see have added a new section here:<span class="Apple-converted-space"> </span><a href="https://wiki.openstack.org/wiki/CrossProjectLiaisons">https://wiki.openstack.org/wiki/CrossProjectLiaisons</a><br>
<br>
</div>
<div>Isn't that enough?<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I replied in the review. We’ll continue the discussion there.</div>
<div><br>
</div>
<div>Everett</div>
<div><br>
</div>
</div>
</body>
</html>