| Message ID | 20190926192457.15053-1-mmichels@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [ovs-dev,v2] Modify release document for OVN. | expand |
Bleep bloop. Greetings Mark Michelson, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. git-am: fatal: sha1 information is lacking or useless (Documentation/internals/release-process.rst). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Modify release document for OVN. The copy of the patch that failed is found in: /var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch When you have resolved this problem, run "git am --resolved". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Please check this out. If you feel there has been an error, please email aconole@redhat.com Thanks, 0-day Robot
Hi Mark, Thanks for updating this. Please see my comments below. On Thu, Sep 26, 2019 at 12:25 PM Mark Michelson <mmichels@redhat.com> wrote: > > This is an RFC to discuss the modified release cycle of OVN compared to > OVS. The document is mostly unchanged, with two exceptions: > > * The release cycle for OVN is modified to be 3 months instead of 6. > * The version numbering for OVN is modified to use the year and month of > the release instead of other numbers. > > Signed-off-by: Mark Michelson <mmichels@redhat.com> > --- > v1 -> v2: Rebased > --- > Documentation/internals/release-process.rst | 60 ++++++++++++++--------------- > 1 file changed, 30 insertions(+), 30 deletions(-) > > diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst > index 3396177b8..8af962b49 100644 > --- a/Documentation/internals/release-process.rst > +++ b/Documentation/internals/release-process.rst > @@ -25,19 +25,19 @@ > OVN Release Process > =================== > > -This document describes the process ordinarily used for OVN > -development and release. Exceptions are sometimes necessary, so all of the > -statements here should be taken as subject to change through rough consensus of > -OVN contributors, obtained through public discussion on, e.g., ovs-dev > -or the #openvswitch IRC channel. > +This document describes the process ordinarily used for OVN development and > +release. Exceptions are sometimes necessary, so all of the statements here > +should be taken as subject to change through rough consensus of OVN > +contributors, obtained through public discussion on, e.g., ovs-dev or the > +#openvswitch IRC channel. > > Release Strategy > ---------------- > > -OVN feature development takes place on the "master" branch. > -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. > +OVN feature development takes place on the "master" branch. 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. > > The process of making a release has the following stages. See `Release > Scheduling`_ for the timing of each stage: > @@ -50,7 +50,7 @@ Scheduling`_ for the timing of each stage: > 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 OVN 2.3.x. > + e.g. "branch-2019.10" for the branch that will yield OVN 2019.10.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. > @@ -65,15 +65,15 @@ Scheduling`_ for the timing of each stage: > 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 OVN repository, makes a release tarball available on > + release the .0 release on its branch, e.g. 2019.10.0 for branch-2019.10. To > + make the actual release, a committer pushes a signed tag named, e.g. > + v2019.10.0, to the OVN 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. > + fixed, committers may make additional releases from a branch: 2019.10.1, > + 2019.10.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 > @@ -97,33 +97,33 @@ titled "Prepare for x.y.0" and increments the version number to x.y. This is > the initial commit on branch-x.y. The second is titled "Prepare for post-x.y.0 > (x.y.90)" and increments the version number to x.y.90. > > -The version number on a release branch is x.y.z, where z is initially 0. > -Making a release requires two commits. The first is titled *Set release dates > -for x.y.z.* and updates NEWS and debian/changelog to specify the release date > -of the new release. This commit is the one made into a tarball and tagged. > -The second is titled *Prepare for x.y.(z+1).* and increments the version number > -and adds a blank item to NEWS with an unspecified date. > +The version number on a release branch is x.y.z, where x is the current year, y > +is the month of the release, and z is initially 0. Making a release requires two > +commits. The first is titled *Set release dates for x.y.z.* and updates NEWS > +and debian/changelog to specify the release date of the new release. This > +commit is the one made into a tarball and tagged. The second is titled *Prepare > +for x.y.(z+1).* and increments the version number and adds a blank item to NEWS > +with an unspecified date. > > Release Scheduling > ------------------ > > -OVN makes releases at the following six-month cadence. All dates are > +OVN makes releases at the following three-month cadence. All dates are > approximate: > > +---------------+----------------+--------------------------------------+ > -| Time (months) | Dates | Stage | > +| Time (months) | Date | Stage | Shouldn't it still be "Dates" instead of "Date"? > +---------------+----------------+--------------------------------------+ > -| T | Mar 1, Sep 1 | Begin x.y release cycle | > +| T | Jan 1, Apr 1 | Begin x.y release cycle | Should it be "Jan 1, Apr 1, July 1, Oct 1"? Same for the following rows. > +---------------+----------------+--------------------------------------+ > -| T + 4 | Jul 1, Jan 1 | "Soft freeze" master for x.y release | > +| T + 2 | Feb 1, May 1 | "Soft freeze" master for x.y release | Should it be T + 1, since T means month? > +---------------+----------------+--------------------------------------+ > -| T + 4.5 | Jul 15, Jan 15 | Fork branch-x.y from master | > +| T + 2.5 | Feb 8, May 8 | Fork branch-x.y from master | T + 1.25 > +---------------+----------------+--------------------------------------+ > -| T + 5.5 | Aug 15, Feb 15 | Release version x.y.0 | > +| T + 2.75 | Feb 22, May 22 | Release version x.y.0 | > +---------------+----------------+--------------------------------------+ > T + 1.75 So we are not only shortening the release cycle but also shortening the time required for branching and releasing. I am ok with that. Acked-by: Han Zhou <hzhou8@ebay.com>
I made the suggested changes and pushed the updated document to master. On 10/2/19 5:17 PM, Han Zhou wrote: > Hi Mark, > > Thanks for updating this. Please see my comments below. > > > On Thu, Sep 26, 2019 at 12:25 PM Mark Michelson <mmichels@redhat.com > <mailto:mmichels@redhat.com>> wrote: > > > > This is an RFC to discuss the modified release cycle of OVN compared to > > OVS. The document is mostly unchanged, with two exceptions: > > > > * The release cycle for OVN is modified to be 3 months instead of 6. > > * The version numbering for OVN is modified to use the year and month of > > the release instead of other numbers. > > > > Signed-off-by: Mark Michelson <mmichels@redhat.com > <mailto:mmichels@redhat.com>> > > --- > > v1 -> v2: Rebased > > --- > > Documentation/internals/release-process.rst | 60 > ++++++++++++++--------------- > > 1 file changed, 30 insertions(+), 30 deletions(-) > > > > diff --git a/Documentation/internals/release-process.rst > b/Documentation/internals/release-process.rst > > index 3396177b8..8af962b49 100644 > > --- a/Documentation/internals/release-process.rst > > +++ b/Documentation/internals/release-process.rst > > @@ -25,19 +25,19 @@ > > OVN Release Process > > =================== > > > > -This document describes the process ordinarily used for OVN > > -development and release. Exceptions are sometimes necessary, so all > of the > > -statements here should be taken as subject to change through rough > consensus of > > -OVN contributors, obtained through public discussion on, e.g., ovs-dev > > -or the #openvswitch IRC channel. > > +This document describes the process ordinarily used for OVN > development and > > +release. Exceptions are sometimes necessary, so all of the > statements here > > +should be taken as subject to change through rough consensus of OVN > > +contributors, obtained through public discussion on, e.g., ovs-dev > or the > > +#openvswitch IRC channel. > > > > Release Strategy > > ---------------- > > > > -OVN feature development takes place on the "master" branch. > > -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. > > +OVN feature development takes place on the "master" branch. > 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. > > > > The process of making a release has the following stages. See `Release > > Scheduling`_ for the timing of each stage: > > @@ -50,7 +50,7 @@ Scheduling`_ for the timing of each stage: > > 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 OVN 2.3.x. > > + e.g. "branch-2019.10" for the branch that will yield OVN 2019.10.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. > > @@ -65,15 +65,15 @@ Scheduling`_ for the timing of each stage: > > 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 OVN repository, makes a release tarball available on > > + release the .0 release on its branch, e.g. 2019.10.0 for > branch-2019.10. To > > + make the actual release, a committer pushes a signed tag named, e.g. > > + v2019.10.0, to the OVN repository, makes a release tarball > available on > > openvswitch.org <http://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. > > + fixed, committers may make additional releases from a branch: > 2019.10.1, > > + 2019.10.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 > > @@ -97,33 +97,33 @@ titled "Prepare for x.y.0" and increments the > version number to x.y. This is > > the initial commit on branch-x.y. The second is titled "Prepare for > post-x.y.0 > > (x.y.90)" and increments the version number to x.y.90. > > > > -The version number on a release branch is x.y.z, where z is initially 0. > > -Making a release requires two commits. The first is titled *Set > release dates > > -for x.y.z.* and updates NEWS and debian/changelog to specify the > release date > > -of the new release. This commit is the one made into a tarball and > tagged. > > -The second is titled *Prepare for x.y.(z+1).* and increments the > version number > > -and adds a blank item to NEWS with an unspecified date. > > +The version number on a release branch is x.y.z, where x is the > current year, y > > +is the month of the release, and z is initially 0. Making a release > requires two > > +commits. The first is titled *Set release dates for x.y.z.* and > updates NEWS > > +and debian/changelog to specify the release date of the new > release. This > > +commit is the one made into a tarball and tagged. The second is > titled *Prepare > > +for x.y.(z+1).* and increments the version number and adds a blank > item to NEWS > > +with an unspecified date. > > > > Release Scheduling > > ------------------ > > > > -OVN makes releases at the following six-month cadence. All dates are > > +OVN makes releases at the following three-month cadence. All dates are > > approximate: > > > > > +---------------+----------------+--------------------------------------+ > > -| Time (months) | Dates | Stage > | > > +| Time (months) | Date | Stage > | > > Shouldn't it still be "Dates" instead of "Date"? > > > > +---------------+----------------+--------------------------------------+ > > -| T | Mar 1, Sep 1 | Begin x.y release cycle > | > > +| T | Jan 1, Apr 1 | Begin x.y release cycle > | > > Should it be "Jan 1, Apr 1, July 1, Oct 1"? Same for the following rows. > > > > +---------------+----------------+--------------------------------------+ > > -| T + 4 | Jul 1, Jan 1 | "Soft freeze" master for x.y > release | > > +| T + 2 | Feb 1, May 1 | "Soft freeze" master for x.y > release | > > Should it be T + 1, since T means month? > > > > +---------------+----------------+--------------------------------------+ > > -| T + 4.5 | Jul 15, Jan 15 | Fork branch-x.y from master > | > > +| T + 2.5 | Feb 8, May 8 | Fork branch-x.y from master > | > > T + 1.25 > > > > +---------------+----------------+--------------------------------------+ > > -| T + 5.5 | Aug 15, Feb 15 | Release version x.y.0 > | > > +| T + 2.75 | Feb 22, May 22 | Release version x.y.0 > | > > > +---------------+----------------+--------------------------------------+ > > > > T + 1.75 > > So we are not only shortening the release cycle but also shortening the > time required for branching and releasing. I am ok with that. > > Acked-by: Han Zhou <hzhou8@ebay.com <mailto:hzhou8@ebay.com>>
diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst index 3396177b8..8af962b49 100644 --- a/Documentation/internals/release-process.rst +++ b/Documentation/internals/release-process.rst @@ -25,19 +25,19 @@ OVN Release Process =================== -This document describes the process ordinarily used for OVN -development and release. Exceptions are sometimes necessary, so all of the -statements here should be taken as subject to change through rough consensus of -OVN contributors, obtained through public discussion on, e.g., ovs-dev -or the #openvswitch IRC channel. +This document describes the process ordinarily used for OVN development and +release. Exceptions are sometimes necessary, so all of the statements here +should be taken as subject to change through rough consensus of OVN +contributors, obtained through public discussion on, e.g., ovs-dev or the +#openvswitch IRC channel. Release Strategy ---------------- -OVN feature development takes place on the "master" branch. -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. +OVN feature development takes place on the "master" branch. 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. The process of making a release has the following stages. See `Release Scheduling`_ for the timing of each stage: @@ -50,7 +50,7 @@ Scheduling`_ for the timing of each stage: 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 OVN 2.3.x. + e.g. "branch-2019.10" for the branch that will yield OVN 2019.10.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. @@ -65,15 +65,15 @@ Scheduling`_ for the timing of each stage: 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 OVN repository, makes a release tarball available on + release the .0 release on its branch, e.g. 2019.10.0 for branch-2019.10. To + make the actual release, a committer pushes a signed tag named, e.g. + v2019.10.0, to the OVN 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. + fixed, committers may make additional releases from a branch: 2019.10.1, + 2019.10.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 @@ -97,33 +97,33 @@ titled "Prepare for x.y.0" and increments the version number to x.y. This is the initial commit on branch-x.y. The second is titled "Prepare for post-x.y.0 (x.y.90)" and increments the version number to x.y.90. -The version number on a release branch is x.y.z, where z is initially 0. -Making a release requires two commits. The first is titled *Set release dates -for x.y.z.* and updates NEWS and debian/changelog to specify the release date -of the new release. This commit is the one made into a tarball and tagged. -The second is titled *Prepare for x.y.(z+1).* and increments the version number -and adds a blank item to NEWS with an unspecified date. +The version number on a release branch is x.y.z, where x is the current year, y +is the month of the release, and z is initially 0. Making a release requires two +commits. The first is titled *Set release dates for x.y.z.* and updates NEWS +and debian/changelog to specify the release date of the new release. This +commit is the one made into a tarball and tagged. The second is titled *Prepare +for x.y.(z+1).* and increments the version number and adds a blank item to NEWS +with an unspecified date. Release Scheduling ------------------ -OVN makes releases at the following six-month cadence. All dates are +OVN makes releases at the following three-month cadence. All dates are approximate: +---------------+----------------+--------------------------------------+ -| Time (months) | Dates | Stage | +| Time (months) | Date | Stage | +---------------+----------------+--------------------------------------+ -| T | Mar 1, Sep 1 | Begin x.y release cycle | +| T | Jan 1, Apr 1 | Begin x.y release cycle | +---------------+----------------+--------------------------------------+ -| T + 4 | Jul 1, Jan 1 | "Soft freeze" master for x.y release | +| T + 2 | Feb 1, May 1 | "Soft freeze" master for x.y release | +---------------+----------------+--------------------------------------+ -| T + 4.5 | Jul 15, Jan 15 | Fork branch-x.y from master | +| T + 2.5 | Feb 8, May 8 | Fork branch-x.y from master | +---------------+----------------+--------------------------------------+ -| T + 5.5 | Aug 15, Feb 15 | Release version x.y.0 | +| T + 2.75 | Feb 22, May 22 | Release version x.y.0 | +---------------+----------------+--------------------------------------+ Contact ------- -Use dev@openvswitch.org to discuss the Open vSwitch and OVN -development and release processes. +Use dev@openvswitch.org to discuss the OVN development and release process.
This is an RFC to discuss the modified release cycle of OVN compared to OVS. The document is mostly unchanged, with two exceptions: * The release cycle for OVN is modified to be 3 months instead of 6. * The version numbering for OVN is modified to use the year and month of the release instead of other numbers. Signed-off-by: Mark Michelson <mmichels@redhat.com> --- v1 -> v2: Rebased --- Documentation/internals/release-process.rst | 60 ++++++++++++++--------------- 1 file changed, 30 insertions(+), 30 deletions(-)