[openstack-dev] [Neutron] Core/Vendor code decomposition

Armando M. armamig at gmail.com
Fri Dec 5 23:04:15 UTC 2014


Hi folks,

For a few weeks now the Neutron team has worked tirelessly on [1].

This initiative stems from the fact that as the project matures, evolution
of processes and contribution guidelines need to evolve with it. This is to
ensure that the project can keep on thriving in order to meet the needs of
an ever growing community.

The effort of documenting intentions, and fleshing out the various details
of the proposal is about to reach an end, and we'll soon kick the tires to
put the proposal into practice. Since the spec has grown pretty big, I'll
try to capture the tl;dr below.

If you have any comment please do not hesitate to raise them here and/or
reach out to us.

tl;dr >>>

>From the Kilo release, we'll initiate a set of steps to change the
following areas:

   - Code structure: every plugin or driver that exists or wants to exist
   as part of Neutron project is decomposed in an slim vendor integration
   (which lives in the Neutron repo), plus a bulkier vendor library (which
   lives in an independent publicly available repo);
   - Contribution process: this extends to the following aspects:
      - Design and Development: the process is largely unchanged for the
      part that pertains the vendor integration; the maintainer team is fully
      auto governed for the design and development of the vendor library;
      - Testing and Continuous Integration: maintainers will be required to
      support their vendor integration with 3rd CI testing; the
requirements for
      3rd CI testing are largely unchanged;
      - Defect management: the process is largely unchanged, issues
      affecting the vendor library can be tracked with whichever
tool/process the
      maintainer see fit. In cases where vendor library fixes need to be
      reflected in the vendor integration, the usual OpenStack defect
management
      apply.
      - Documentation: there will be some changes to the way plugins and
      drivers are documented with the intention of promoting discoverability of
      the integrated solutions.
   - Adoption and transition plan: we strongly advise maintainers to stay
   abreast of the developments of this effort, as their code, their CI, etc
   will be affected. The core team will provide guidelines and support
   throughout this cycle the ensure a smooth transition.

To learn more, please refer to [1].

Many thanks,
Armando

[1] https://review.openstack.org/#/c/134680
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141205/e9293c76/attachment.html>


More information about the OpenStack-dev mailing list