release-process.rst: Add "soft freeze" stage.

The last few OVS releases have included a "soft freeze" stage in the
release process, but this stage has never been formalized in the
documentation.  This adds a description.

Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ian Stokes <ian.stokes@intel.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>

1 files changed, 49 insertions, 39 deletions

diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst
index 7ecac0a5f..89c117724 100644
--- a/Documentation/internals/release-process.rst
+++ b/Documentation/internals/release-process.rst
@@ -39,33 +39,41 @@ Ordinarily, new features are rebased against master and applied directly.  For
 features that take significant development, sometimes it is more appropriate to
 merge a separate branch into master; please discuss this on ovs-dev in advance.
 
-Periodically, the OVS developers fork a branch from master to become an
-official release.  These release branches are named for expected release
-number, e.g. "branch-2.3" for the branch that will yield Open vSwitch 2.3.x.
-Release branches should receive only bug fixes, not new features.  Bug fixes
-applied to release branches should be backports of corresponding bug fixes to
-the master branch, except for bugs present only on release branches (which are
-rare in practice).
-
-Sometimes there can be exceptions to the rule that a release branch receives
-only bug fixes.  In particular, after a release branch is created, but before
-the first actual release from that branch, it can be appropriate to add
-features.  Like bug fixes, new features on release branches should be backports
-of the corresponding commits on the master branch.  Features to be added to
-release branches should be limited in scope and risk and discussed on ovs-dev
-before creating the branch.
-
-After a period of testing and stabilization, and rough consensus obtained from
-contributors that the release is ready, the developers release the .0 release
-on its branch, e.g. 2.3.0 for branch-2.3.  To make the actual release, a
-developer pushes a signed tag named, e.g. v2.3.0, to the Open vSwitch
-repository, makes a release tarball available on openvswitch.org, and posts a
-release announcement to ovs-announce.
-
-As a number of bug fixes accumulate, or after important bugs or vulnerabilities
-are fixed, the OVS developers may make additional releases from a branch:
-2.3.1, 2.3.2, and so on.  The process is the same for these additional release
-as for a .0 release.
+The process of making a release has the following stages.  See `Release
+Scheduling`_ for the timing of each stage:
+
+1. "Soft freeze" of the master branch.
+
+   During the freeze, we ask committers to refrain from applying patches that
+   add new features unless those patches were already being publicly discussed
+   and reviewed before the freeze began.  Bug fixes are welcome at any time.
+   Please propose and discuss exceptions on ovs-dev.
+ 
+2. Fork a release branch from master, named for the expected release number,
+   e.g. "branch-2.3" for the branch that will yield Open vSwitch 2.3.x.
+
+   Release branches are intended for testing and stabilization.  At this stage
+   and in later stages, they should receive only bug fixes, not new features.
+   Bug fixes applied to release branches should be backports of corresponding
+   bug fixes to the master branch, except for bugs present only on release
+   branches (which are rare in practice).
+
+   At this stage, sometimes there can be exceptions to the rule that a release
+   branch receives only bug fixes.  Like bug fixes, new features on release
+   branches should be backports of the corresponding commits on the master
+   branch.  Features to be added to release branches should be limited in scope
+   and risk and discussed on ovs-dev before creating the branch.
+
+3. When committers come to rough consensus that the release is ready, they
+   release the .0 release on its branch, e.g. 2.3.0 for branch-2.3.  To make
+   the actual release, a committer pushes a signed tag named, e.g. v2.3.0, to
+   the Open vSwitch repository, makes a release tarball available on
+   openvswitch.org, and posts a release announcement to ovs-announce.
+
+4. As bug fixes accumulate, or after important bugs or vulnerabilities are
+   fixed, committers may make additional releases from a branch: 2.3.1, 2.3.2,
+   and so on.  The process is the same for these additional release as for a .0
+   release.
 
 At most two release branches are formally maintained at any given time: the
 latest release and the latest release designed as LTS.  An LTS release is one
@@ -99,18 +107,20 @@ and adds a blank item to NEWS with an unspecified date.
 Release Scheduling
 ------------------
 
-Open vSwitch makes releases at the following six-month cadence, which of course
-is subject to change.
-
-+-------------------+-----------------------+--------------------------------------+
-| **Time (months)** | **Approximate Dates** | **Event**                            |
-+-------------------+-----------------------+--------------------------------------+
-| T                 | Mar 1, Sep 1          | Release cycle for version x.y begins |
-+-------------------+-----------------------+--------------------------------------+
-| T + 4             | Jul 1, Jan 1          | branch-x.y forks from master         |
-+-------------------+-----------------------+--------------------------------------+
-| T + 5.5           | Aug 15, Feb 15        | branch-x.y released as version x.y.0 |
-+-------------------+-----------------------+--------------------------------------+
+Open vSwitch makes releases at the following six-month cadence.  All dates are
+approximate:
+
++---------------+----------------+--------------------------------------+
+| Time (months) | Dates          | Stage                                |
++---------------+----------------+--------------------------------------+
+| T             | Mar 1, Sep 1   | Begin x.y release cycle              |
++---------------+----------------+--------------------------------------+
+| T + 4         | Jul 1, Jan 1   | "Soft freeze" master for x.y release |
++---------------+----------------+--------------------------------------+
+| T + 4.5       | Jul 15, Jan 15 | Fork branch-x.y from master          |
++---------------+----------------+--------------------------------------+
+| T + 5.5       | Aug 15, Feb 15 | Release version x.y.0                |
++---------------+----------------+--------------------------------------+
 
 Contact
 -------