community:openvswitch
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
community:openvswitch [2015/04/22 12:00] Mark D. Gray [Code repository] |
community:openvswitch [2015/08/22 18:13] (current) Mark D. Gray [Open vSwitch Releases] |
||
|---|---|---|---|
| Line 4: | Line 4: | ||
| 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]]. | 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. | ||
| Line 33: | Line 45: | ||
| * All features should be submitted to Open vSwitch via the mailing lists. | * 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. | + | * 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: | * 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. | * 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. | + | * Engage with fellow travelers that may be interested in working with you on the feature. |
| * Get feedback from key community members on your approach. | * 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. | + | * 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: | * 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: | * 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. | * Patchsets should be made up of small, logically separate, bisectable patches. | ||
| Line 49: | Line 65: | ||
| * All patches submitted must include a ''%%Signed-off-by%%'' tag. | * 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 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. | ||
| - | Currently, Open vSwitch does not have a regular release cadence. Releases are made made | + | ==== Open vSwitch Releases ==== |
| - | *** Describe Open vswitch planning process and release schedule/process here *** | + | * 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 planning process ==== | ||
community/openvswitch.1429704016.txt.gz · Last modified: 2015/04/22 12:00 by Mark D. Gray
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
