Re: [openstack-dev] [api] APIImpact flag for specs
I’ve also added APIImpact flag info to the Git Commit Messages page [1]. Everett [1] https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references On Nov 19, 2014, at 5:23 PM, Everett Toews everett.to...@rackspace.commailto:everett.to...@rackspace.com wrote: On Nov 13, 2014, at 2:06 PM, Everett Toews everett.to...@rackspace.commailto:everett.to...@rackspace.com wrote: On Nov 12, 2014, at 10:45 PM, Angus Salkeld asalk...@mirantis.commailto:asalk...@mirantis.com wrote: On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews everett.to...@rackspace.commailto: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? I replied in the review. We’ll continue the discussion there. The cross project liaisons are big help but the APIImpact flag let’s the API WG automate discovery of API changing specs. It's just one more tool in the box to help us find changes that impact the API. Note that the patch says nothing about requiring a review from someone associated with the API WG. If you add the APIImpact flag and nobody comes along to review it, continue on as normal. The API WG is not intended to be a gatekeeper of every change to every API. As you say that doesn't scale. We don't want to be a bottleneck. However, tools such as the APIImpact flag can help us be more effective. (Angus suggested I give my review comment a bit more visibility. I agree :) Everett ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [api] APIImpact flag for specs
On Nov 13, 2014, at 2:06 PM, Everett Toews everett.to...@rackspace.commailto:everett.to...@rackspace.com wrote: On Nov 12, 2014, at 10:45 PM, Angus Salkeld asalk...@mirantis.commailto:asalk...@mirantis.com wrote: On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews everett.to...@rackspace.commailto: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? I replied in the review. We’ll continue the discussion there. The cross project liaisons are big help but the APIImpact flag let’s the API WG automate discovery of API changing specs. It's just one more tool in the box to help us find changes that impact the API. Note that the patch says nothing about requiring a review from someone associated with the API WG. If you add the APIImpact flag and nobody comes along to review it, continue on as normal. The API WG is not intended to be a gatekeeper of every change to every API. As you say that doesn't scale. We don't want to be a bottleneck. However, tools such as the APIImpact flag can help us be more effective. (Angus suggested I give my review comment a bit more visibility. I agree :) Everett ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] APIImpact flag for specs
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
Re: [openstack-dev] [api] APIImpact flag for specs
On Nov 12, 2014, at 10:45 PM, Angus Salkeld asalk...@mirantis.commailto:asalk...@mirantis.com wrote: On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews everett.to...@rackspace.commailto: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? I replied in the review. We’ll continue the discussion there. Everett ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] APIImpact flag for specs
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
