Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== OPNFV Open vSwitch community page ======

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|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|ovs-nfv]] project.

==== OPNFV related features ====

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

  - 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
  - A requirement will result in one or more features for which a design should be drafted in ''repository/design_docs/reference_document.rst''
  - These files should be proposed for review in [[http://gerrit.opnfv.org|OPNFV's Gerrit]]
  - After a successful community sanity check, verifying that the docs have sufficient implementation details, they should be proposed to the [[discuss@openvswitch.org|discuss]] mailing list if they are just a descriptive document or the [[dev@openvswitch.com|dev]] mailing list if they are an RFC code contribution or docs contribution.
  - Community comments are to be expected and multiple revisions may be required upstream before a direction has been agreed.


==== Communication =====

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

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

IRC: #openvswitch on irc.freenode.net

==== Code repository ====

  * Code is available at [[https://github.com/openvswitch/ovs.git|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 [[http://patchwork.openvswitch.org/project/openvswitch/list/|patchwork server]] but has not been updated in a while.

==== License ====

Open vSwitch is primarily licensed under the Apache 2 license.

==== Feature Submission ====

  * 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 [[http://openvswitch.org/pipermail/dev/2015-January/050380.html|here]] and [[http://openvswitch.org/pipermail/dev/2015-January/050379.html|here]]
      * In the form of an early ''%%RFC%%'' patch on the dev mailing list. An example can be seen [[http://openvswitch.org/pipermail/dev/2015-March/052680.html|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 [[http://openvswitch.org/pipermail/dev/2015-February/051344.html|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 [[https://github.com/openvswitch/ovs/blob/master/CONTRIBUTING.md|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.
              * <code>make check</code>
              * <code>make distcheck</code>
          * All patches submitted must include a ''%%Signed-off-by%%'' tag.
      * Open vSwitch coding style can be found [[https://github.com/openvswitch/ovs/blob/master/CodingStyle.md|here]]
==== Open vSwitch Roles ====
  * 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 [[https://github.com/openvswitch/ovs/blob/master/AUTHORS|authors]] are those who have made contributions.

==== Open vSwitch Releases ====
  * 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 [[https://github.com/openvswitch/ovs/blob/master/NEWS|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 [[http://openvswitch.org/pipermail/discuss/2014-December/015884.html|future]]
==== Open vSwitch planning process ====

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

==== OpenDaylight in-flight Open vSwitch features ====
Wiki

User Tools

Site Tools

Page Tools
