Rather than establish a project for individual projects, the OPNFV community has agreed to work on establishing focus community groups where we will describe community engagement practices, identify community leaders, manage our contributions toward those communities and generally get ourselves organised well enough to be a benefit, rather than a burden, to our source communities.

In general, we would like to have a consistent process for feature requests across OPNFV projects. Since the bar in terms of structure and information seems to be highest for OpenStack, we will align feature request documentation on the OpenStack blueprint process. The process is defined for requirements projects.

However, in the case of Open vSwitch specifically, because there were a number of features which were eagerly requested by members, feature improvements for Open vSwitch are being tracked in the ovs-nfv project.

To facilitate the work of developers submitting features to Open vSwitch, we have instituted a process for requirements projects which consists of the following:

1. Projects first create an OPNFV requirement document in Markdown in the project repository: repository/requirements/reference_document.rst - this document should describe the goal at a high level for OPNFV consumers
2. A requirement will result in one or more features for which a design should be drafted in repository/design_docs/reference_document.rst
3. These files should be proposed for review in OPNFV's Gerrit
4. After a successful community sanity check, verifying that the docs have sufficient implementation details, they should be proposed to the discuss mailing list if they are just a descriptive document or the dev mailing list if they are an RFC code contribution or docs contribution.
5. Community comments are to be expected and multiple revisions may be required upstream before a direction has been agreed.

All collaboration with the Open vSwitch community takes place via Open vSwitch mailing lists and the Open vSwitch IRC channel:

• dev@openvswitch.org: Code contributions, development discussions and development proposals.
• discuss@openvswitch.org: General discussions, questions and queries. Discuss plans and design decisions.
• announce@openvswitch.org: Announcements from the Open vSwitch maintainers. e.g. Release announcements, conference call for papers, etc.
• build@openvswitch.org: Nightly build reports
• git@openvswitch.org: Notifications of changes merged into the git repository.

IRC: #openvswitch on irc.freenode.net

• Code is available at https://github.com/openvswitch/ovs.git
• Development takes place on the master branch
• Releases are tagged with the format vX.Y.Z e.g. v2.3.1
• Branches exist for each release with the format branch-X.Y e.g. branch-2.3 at https://github.com/openvswitch/ovs/tree/branch-2.3. The Open vSwitch maintainers backport bugfixes to these branches.
• Open vSwitch has a patchwork server but has not been updated in a while.

Open vSwitch is primarily licensed under the Apache 2 license.

• All features should be submitted to Open vSwitch via the mailing lists.
• Like with most opensource communities, it is recommended that you engage early with the community in order to gain consensus.
• As such, it is recommended that you discuss what feature you are planning to implement at an earlier stage in order to:
  • Inform the community what you are working on to ensure there is no duplication of effort.
  • Engage with fellow travelers that may be interested in working with you on the feature.
  • Get feedback from key community members on your approach.
• Early discussion can take place in a few ways:
  • On the discuss or dev mailing list by outlining a description of your requirements and design. An example for OVN can be seen here and here
  • In the form of an early RFC patch on the dev mailing list. An example can be seen here.
  • A hybrid approach could be to update the Open vSwitch documentation describing your change as if it had been implemented. A good example of this was the Open vSwitch OVN initial patchset here
• When a feature is ready for formal submission in should be submitted following the rules specified by the Open vSwitch community:
  • Features should be developed against the master branch.
  • A detailed description of the patch submission process can be found here. Although this document gives a detailed outline of the patch submission process, the key points are:
    • Patchsets should be made up of small, logically separate, bisectable patches.
    • Patches are sent via email inline.
    • The subject of the patch should indicate that it is a patch using [PATCH] and should also indicate the area of the code being modified and a brief description of the change.
    • All patches must pass the Open vSwitch unit tests.

      • make check

      • make distcheck

    • All patches submitted must include a Signed-off-by tag.
  • Open vSwitch coding style can be found here

• Open vSwitch committers have push access to the Open vSwitch git repository.
• Committers are nominated and accepted using the following procedure :http://openvswitch.org/development/committer-grant-revocation/
• Open vSwitch authors are those who have made contributions.

• Currently, Open vSwitch does not have a regular release cadence.
• Some releases are designated as LTS releases. These are roughly every year but not deterministic.
• Details of each release (including the upcoming release) can be found in NEWS
• Releases are made when key changes have been submitted to master branch.
• OVS 2.4 has been released (http://openvswitch.org/pipermail/discuss/2015-August/018569.html)
• Regular releases of Open vSwitch may happen in the future

Open vSwitch has a lightweight governance process for proposing and accepting new features.