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.

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 on the discuss mailing list or in the form of an early RFC patch on the dev mailing list.
• 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. Open vSwitch 2.4 has been delayed from previous |plans because of a delay of the connection tracking feature in the Linux Kernel. As can be seen, planning and release of features is quite dynamic. * Regular releases of Open vSwitch may happen in the future

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