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 earlier with the community in order to gain some 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 travellers that may be interested in working with you on your proposal.
  • 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:
  • 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

Currently, Open vSwitch does not have a regular release cadence. Releases are made made * Describe Open vswitch planning process and release schedule/process here *

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