Re: [PATCH v1] doc: add guidelines on stable and lts releases

Re: [PATCH v1] doc: add guidelines on stable and lts releases

[Yuanhan Liu]

On Fri, Jan 13, 2017 at 01:06:22PM +0000, John McNamara wrote:
> Add document explaining the current Stable and LTS process.

John, great doc! Thanks.

Here I got one more thing to discuss about the stable release: the release
cycle. (I may better start a new thread, but I hope it would be a short
discussion, so I didn't bother with that).

16.07 as a first trial of stable release, I made a proposal to have 2
releases: v16.07.1 shortly after v16.11-rc1 and v16.07.2 shortly after 
v16.11. While the gap between v16.07 and v16.11 are 4 months, doing a
release each 2 month doesn't seem that bad. It may a bit stretch then
because the gap is shorter (3 months) since 16.11. Besides, the validation
team here are pretty busy after rc1, meaning it doesn't seem a good idea
to have another release shortly after that: they may quite be burdened.

So I'm proposing to make one stable/LTS release per release cycle. For
example, we will have v16.11.1 shortly after v17.02, and judging that
v16.11 is a LTS release, we will have v16.11.2 after v17.05, and so on.

And my plan towards a release is, I will monitor (by a script) the
official tree regularly (normally, weekly), and pick patches from there
if any to a specific stable branch. As before, an email notification will
be sent to the author and all email addresses mentioned in the patch
(normally, they are maintainers, reviewers, etc) once a patch is picked
as a stable candidate.

Doing this regularly, hopefully, tells people that DPDK stable/LTS is
live and actively maintained.

Any objections? If no, I could start picking patches since the beginning
of next week.

Thanks.

	--yliu

Re: [PATCH v1] doc: add guidelines on stable and lts releases

[Thomas Monjalon]

2017-01-20 16:43, Yuanhan Liu:
> 16.07 as a first trial of stable release, I made a proposal to have 2
> releases: v16.07.1 shortly after v16.11-rc1 and v16.07.2 shortly after 
> v16.11. While the gap between v16.07 and v16.11 are 4 months, doing a
> release each 2 month doesn't seem that bad. It may a bit stretch then
> because the gap is shorter (3 months) since 16.11. Besides, the validation
> team here are pretty busy after rc1, meaning it doesn't seem a good idea
> to have another release shortly after that: they may quite be burdened.
> 
> So I'm proposing to make one stable/LTS release per release cycle. For
> example, we will have v16.11.1 shortly after v17.02, and judging that
> v16.11 is a LTS release, we will have v16.11.2 after v17.05, and so on.
> 
> And my plan towards a release is, I will monitor (by a script) the
> official tree regularly (normally, weekly), and pick patches from there
> if any to a specific stable branch. As before, an email notification will
> be sent to the author and all email addresses mentioned in the patch
> (normally, they are maintainers, reviewers, etc) once a patch is picked
> as a stable candidate.
> 
> Doing this regularly, hopefully, tells people that DPDK stable/LTS is
> live and actively maintained.
> 
> Any objections? If no, I could start picking patches since the beginning
> of next week.

OK, thanks Yuanhan.

Have you received any proposal to help or maintain a future stable branch?

Re: [PATCH v1] doc: add guidelines on stable and lts releases

[Yuanhan Liu]

On Wed, Feb 08, 2017 at 06:39:23AM -0800, Thomas Monjalon wrote:
> 2017-01-20 16:43, Yuanhan Liu:
> > 16.07 as a first trial of stable release, I made a proposal to have 2
> > releases: v16.07.1 shortly after v16.11-rc1 and v16.07.2 shortly after 
> > v16.11. While the gap between v16.07 and v16.11 are 4 months, doing a
> > release each 2 month doesn't seem that bad. It may a bit stretch then
> > because the gap is shorter (3 months) since 16.11. Besides, the validation
> > team here are pretty busy after rc1, meaning it doesn't seem a good idea
> > to have another release shortly after that: they may quite be burdened.
> > 
> > So I'm proposing to make one stable/LTS release per release cycle. For
> > example, we will have v16.11.1 shortly after v17.02, and judging that
> > v16.11 is a LTS release, we will have v16.11.2 after v17.05, and so on.
> > 
> > And my plan towards a release is, I will monitor (by a script) the
> > official tree regularly (normally, weekly), and pick patches from there
> > if any to a specific stable branch. As before, an email notification will
> > be sent to the author and all email addresses mentioned in the patch
> > (normally, they are maintainers, reviewers, etc) once a patch is picked
> > as a stable candidate.
> > 
> > Doing this regularly, hopefully, tells people that DPDK stable/LTS is
> > live and actively maintained.
> > 
> > Any objections? If no, I could start picking patches since the beginning
> > of next week.
> 
> OK, thanks Yuanhan.
> 
> Have you received any proposal to help or maintain a future stable branch?

Nope, and I think I need help here. Since v17.02, I have to maintain two
stable releases for each cycle, which is a bit burden to me.

I would appreciate if anyone has interest in maintain the stable releases
while I'm focusing on the LTS release. I have made most of the work automatic
(I wrote quite few scripts to help myself). It should not be a tough task
for anyone volunteering this task. 


	--yliu

Re: [PATCH v1] doc: add guidelines on stable and lts releases

[Thomas Monjalon]

2017-01-13 13:06, John McNamara:
> Add document explaining the current Stable and LTS process.
> 
> Signed-off-by: John McNamara <john.mcnamara@intel.com>

Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>

Applied, thanks

Re: [PATCH v1] doc: add guidelines on stable and lts releases

[Mcnamara, John]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, January 13, 2017 4:29 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org; Liu, Yuanhan <yuanhan.liu@intel.com>
> Subject: Re: [PATCH v1] doc: add guidelines on stable and lts releases
> 
> 2017-01-13 13:14, Mcnamara, John:
> > Just a reminder that DPDK 16.07 was a stable release, 16.11 is a
> > stable release and it will also become the 2 year LTS release.
> 
> There should be a roadmap for the stable releases, giving end of life
> dates.
> 
> What about updating this page? http://dpdk.org/dev/roadmap

Good point. That was planned. We'll look at pushing up a patch to the Roadmap page.

John

Re: [PATCH v1] doc: add guidelines on stable and lts releases

[Thomas Monjalon]

2017-01-13 13:14, Mcnamara, John:
> Just a reminder that DPDK 16.07 was a stable release, 16.11 is a stable
> release and it will also become the 2 year LTS release.

There should be a roadmap for the stable releases,
giving end of life dates.

What about updating this page? http://dpdk.org/dev/roadmap

Re: [PATCH v1] doc: add guidelines on stable and lts releases

[Mcnamara, John]

> -----Original Message-----
> From: Mcnamara, John
> Sent: Friday, January 13, 2017 1:06 PM
> To: dev@dpdk.org
> Cc: Liu, Yuanhan <yuanhan.liu@intel.com>; thomas.monjalon@6wind.com;
> Mcnamara, John <john.mcnamara@intel.com>
> Subject: [PATCH v1] doc: add guidelines on stable and lts releases
> 
> Add document explaining the current Stable and LTS process.

Hi,

Just a reminder that DPDK 16.07 was a stable release, 16.11 is a stable
release and it will also become the 2 year LTS release.

Some links:

    http://dpdk.org/ml/archives/stable/ - Mailing list
    http://dpdk.org/download - Download page for mainline and stable release
    http://fast.dpdk.org/rel/ - Stable release tarballs

If you are a downstream consumer of DPDK and would like to influence how the
Stable/LTS releases are working, or should work, then let us know.

John

[PATCH v1] doc: add guidelines on stable and lts releases

[John McNamara]

Add document explaining the current Stable and LTS process.

Signed-off-by: John McNamara <john.mcnamara@intel.com>
---

V1: For background see previous discussions on Stable and LTS releses:

   http://dpdk.org/ml/archives/dev/2016-July/044848.html
   http://dpdk.org/ml/archives/dev/2016-June/040256.html

doc/guides/contributing/index.rst  |  1 +
 doc/guides/contributing/stable.rst | 99 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 100 insertions(+)
 create mode 100644 doc/guides/contributing/stable.rst

diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index f6af317..329b678 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -10,4 +10,5 @@ Contributor's Guidelines
     versioning
     documentation
     patches
+    stable
     cheatsheet
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
new file mode 100644
index 0000000..735e116
--- /dev/null
+++ b/doc/guides/contributing/stable.rst
@@ -0,0 +1,99 @@
+.. stable_lts_releases:
+
+DPDK Stable Releases and Long Term Support
+==========================================
+
+This section sets out the guidelines for the DPDK Stable Releases and the DPDK
+Long Term Support releases (LTS).
+
+
+Introduction
+------------
+
+The purpose of the DPDK Stable Releases is to maintain releases of DPDK with
+backported fixes over an extended period of time. This provides downstream
+consumers of DPDK with a stable target on which to base applications or
+packages.
+
+The Long Term Support release (LTS) is a designation applied to a Stable
+Release to indicate longer term support.
+
+
+Stable Releases
+---------------
+
+Any major release of DPDK can be designated as a Stable Release if a
+maintainer volunteers to maintain it.
+
+A Stable Release is used to backport fixes from an ``N`` release back to an
+``N-1`` release, for example, from 16.11 to 16.07.
+
+The duration of a stable is one complete release cycle (3 months). It can be
+longer, up to 1 year, if a maintainer continues to support the stable branch,
+or if users supply backported fixes, however the explicit commitment should be
+for one release cycle.
+
+The release cadence is determined by the maintainer based on the number of
+bugfixes and the criticality of the bugs. Releases should be coordinated with
+the validation engineers to ensure that a tagged release has been tested.
+
+
+LTS Release
+-----------
+
+A stable release can be designated as an LTS release based on community
+agreement and a commitment from a maintainer. An LTS release will have a
+maintenance duration of 2 years.
+
+The current DPDK LTS release is 16.11.
+
+It is anticipated that there will be at least 4 releases per year of the LTS
+or approximately 1 every 3 months. However, the cadence can be shorter or
+longer depending on the number and criticality of the backported
+fixes. Releases should be coordinated with the validation engineers to ensure
+that a tagged release has been tested.
+
+
+What changes should be backported
+---------------------------------
+
+Backporting should be limited to bug fixes.
+
+Features should not be backported to stable releases. It may be acceptable, in
+limited cases, to back port features for the LTS release where:
+
+* There is a justifiable use case (for example a new PMD).
+* The change is non-invasive.
+* The work of preparing the backport is done by the proposer.
+* There is support within the community.
+
+
+The Stable Mailing List
+-----------------------
+
+The Stable and LTS release are coordinated on the stable@dpdk.org mailing
+list.
+
+All fix patches to the master branch that are candidates for backporting
+should also be CCed to the `stable@dpdk.org <http://dpdk.org/ml/listinfo/stable>`_
+mailing list.
+
+
+Releasing
+---------
+
+A Stable Release will be released by:
+
+* Tagging the release with YY.MM.n (year, month, number).
+* Uploading a tarball of the release to dpdk.org.
+* Sending an announcement to the `announce@dpdk.org <http://dpdk.org/ml/listinfo/announce>`_
+  list.
+
+Stable release are available on the `dpdk.org download page <http://dpdk.org/download>`_.
+
+
+ABI
+---
+
+The Stable Release should not be seen as a way of breaking or circumventing
+the DPDK ABI policy.
-- 
2.7.4