)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6159,"name":"Flavio Percoco Premoli","display_name":"flaper87","email":"flavio.percoco@flyrlabs.com","username":"flaper87"},"change_message_id":"f457e39f143b02208e6d350371ea41459f18070e","unresolved":false,"context_lines":[{"line_number":17,"context_line":"does not expose any Capabilities to end users of OpenStack clouds"},{"line_number":18,"context_line":"directly via an API, it does provide code that is or may in the future"},{"line_number":19,"context_line":"be invoked by Capabilities that are required by Interoperability"},{"line_number":20,"context_line":"Guidelines."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"At present, the DefCore Committee would be unable to consider adding"},{"line_number":23,"context_line":"part or all of neutron-lib as a Designated Section to future Guidelines"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"7a8ec9b2_e51401a1","line":20,"updated":"2016-09-19 06:49:47.000000000","message":"As someone not familiar with neutron-lib, I\u0027m curious to know what capabilities you\u0027re referring to here. I\u0027m a bit surprised to know that the use of this library may affect interoperability in such a way that we need to have it as part of DefCore. I may be just missing some info, though.\n\nAs you pointed out, it\u0027s weird (at least to me) to have this tag being applied to libraries.","commit_id":"0f90eed0c9fca506950aab3399139a63645fbfee"},{"author":{"_account_id":6754,"name":"Mark T. Voelker","email":"markvoelker@gmail.com","username":"mvoelker"},"change_message_id":"70eb3706bde3bac6661e7baf4444c152decf6b24","unresolved":false,"context_lines":[{"line_number":17,"context_line":"does not expose any Capabilities to end users of OpenStack clouds"},{"line_number":18,"context_line":"directly via an API, it does provide code that is or may in the future"},{"line_number":19,"context_line":"be invoked by Capabilities that are required by Interoperability"},{"line_number":20,"context_line":"Guidelines."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"At present, the DefCore Committee would be unable to consider adding"},{"line_number":23,"context_line":"part or all of neutron-lib as a Designated Section to future Guidelines"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"7a8ec9b2_322458c5","line":20,"in_reply_to":"7a8ec9b2_e51401a1","updated":"2016-09-19 13:32:03.000000000","message":"Bear in mind that DefCore has two requirements: you must pass certain tests (thus proving you support certain Capabilities[1]), and you must use certain code in order to pass those tests (i.e. the Designated Sections [2] of upstream code rather than something you wrote yourself).  So, when we talk about interoperability here, just providing a passing test result is insufficient if you also want to use the OpenStack name.  Designated Sections mean among other things that you can\u0027t fork OpenStack and still call it OpenStack (even if it behaves the same): they ensure that work done by the community is what\u0027s used for the trademark (which also generally helps ensure that changes get contributed upstream).  That protection is what we may want to consider extending to things like neutron-lib.\n\n\nAt the moment neutron-lib is fairly small (it\u0027s less than a year old) and has fairly simple things in it: constant definitions, base classes, type converters, exception definitions, etc.  Nevertheless, you\u0027ll see that neutron-lib is imported in many places in trunk, including neutron/db, neutron/api, and neutron/agent, neutron/extensions, and neutron/objects (which are all Designated Sections in the 2016.08 Guideline).  More generally, neutron-lib seems to be on path to be a more and more important cog in the machinery going forward, and therefore something the community has an interest in ensuring that community-developed code is used for in OpenStack Powered products.  \n\n\n\nWhat makes neutron-lib a particularly interesting case is that what we have here is a bunch of common routines and constants and the like that were previously in the main Neutron repo (and covered as a Designated Section previously) which are now in a separate repo (which means they\u0027re not covered in Designated Sections any longer).  So in other words, if we don\u0027t allow the DefCore Committee to consider making neutron-lib a Designated Section there\u0027s code here that may lose it\u0027s protection simply because it\u0027s been refactored.  Put another way: the code in question here is basically code the TC used to consider tc-approved-release, so it would seem a bit odd if the TC now would not consider it tc-approved-release simply because the project team refactored it into a library that resides in a different repo under the same project umbrella.\n\n\nAlso worth pointing out just in case folks aren\u0027t clear here: the TC adding tc-approved-release to neutron-lib doesn\u0027t automatically make neutron-lib a Designated Section.  It merely allows the DefCore Committee to consider it for inclusion--the Committee may then decide to add parts of neutron-lib to future Guidelines as Designated Sections, or all of it, or none of it.  So, think of this tag as a bit of gatekeeping device.  Without it, the DefCore Committee can\u0027t even consider the code in question.\n\n\n[1] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/Lexicon.rst#n16\n[2] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/Lexicon.rst#n54","commit_id":"0f90eed0c9fca506950aab3399139a63645fbfee"}]}