[ovs-dev] [PATCH] release-process.rst: Add "soft freeze" stage.

Ian Stokes ian.stokes at intel.com
Thu Jul 5 18:33:06 UTC 2018


On 7/2/2018 9:57 PM, Ben Pfaff wrote:
> 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 at ovn.org>
> ---
>   Documentation/internals/release-process.rst | 87 ++++++++++++++++-------------
>   1 file changed, 48 insertions(+), 39 deletions(-)
> 
> diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst
> index 7ecac0a5f5d3..293fb13683f7 100644
> --- a/Documentation/internals/release-process.rst
> +++ b/Documentation/internals/release-process.rst
> @@ -39,33 +39,40 @@ 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. > +

Would there ever be an exception here? I'm thinking if a patch is 
submitted for an existing feature and the patch is deemed low risk (i.e. 
fairly simple but useful). I'm aware we want to draw up a deadline and 
stick to it but in the case like this should an exception be requested 
from a maintainer? Or do we stick to hard deadline and only previously 
discussed patches allowed.

> +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 +106,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                |
> ++---------------+----------------+--------------------------------------+
>   

Other than my query above this looks good, I like the 4 week 
stabilization period for beg fixes before release. Should be helpful.

Ian
>   Contact
>   -------
> 



More information about the dev mailing list