[dpdk-dev] DPDK Stable Releases and Long Term Support

[dpdk-dev] DPDK Stable Releases and Long Term Support

[Mcnamara, John]

This document sets out the guidelines for DPDK Stable Releases and Long Term
Support releases (LTS) based on the initial RFC and comments:
http://dpdk.org/ml/archives/dev/2016-June/040256.html.

In particular it incorporates suggestions for a Stable Release structure as
well as a Long Term Support release.


Introduction
------------

The purpose of the DPDK Stable Releases will be to maintain releases of DPDK
with backported fixes over an extended period of time. This will provide
downstream consumers of DPDK with a stable target on which to base
applications or packages.

The Long Term Support release (LTS) will be a designation applied to a Stable
Release to indicate longer 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 will be used to backport fixes from a N release back to a N-1
release, for example, from 16.11 to 16.07.

The duration of a stable release should be one complete release cycle. 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 can be determined by the maintainer based on the number of
bugfixes and the criticality of the bugs. However, 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.

It is anticipated that there should 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.


Initial Stable Release
----------------------

The initial DPDK Stable Release will be 16.07. It will be viewed as a trial of
the Stable Release/LTS policy to determine what are the best working practices
for DPDK.

The maintainer for the initial release will be Yuanhan Liu
<yuanhan.liu@linux.intel.com>. It is hoped that other community members will
volunteer as maintainers for other Stable Releases.

The initial targeted release for LTS is proposed to be 16.11 based on the
results of the work carried out on the 16.07 Stable Release.

A list has been set up for Stable Release/LTS specific discussions:
<stable@dpdk.org>. This address can also be used for CCing maintainers on bug
fix submissions.


What changes should be backported
---------------------------------

The 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.


Testing
-------

Stable and LTS releases should be tested before release/tagging.

Intel will provide validation engineers to test the 16.07 Stable Release and
the initial LTS tree. Other community members should provide testing for other
stable releases.

The validation will consist of compilation testing on the range of OSes
supported by the master release and functional/performance testing on the
current major/LTS release of the following OSes:

* Ubuntu
* RHEL
* SuSE
* FreeBSD


Releasing
---------

A Stable Release will be released by:

* Tagging the release with YY.MM.nn (year, month, number) or similar.
* Uploading a tarball of the release to dpdk.org.
* Sending an announcement to the <announce@dpdk.org> list.


ABI
---

The Stable Release should not be seen as a way of breaking or circumventing
the DPDK ABI policy.


Review of the Stable Release/LTS guidelines
-------------------------------------------

This document serves as a set of guidelines for the planned Stable
Releases/LTS activities. However, the actual process can be reviewed and
amended over time, based on experiences and feedback.

Re: [dpdk-dev] DPDK Stable Releases and Long Term Support

[Yuanhan Liu]

On Thu, Jul 28, 2016 at 12:33:18PM +0000, Mcnamara, John wrote:
> Initial Stable Release
> ----------------------
> 
> The initial DPDK Stable Release will be 16.07. It will be viewed as a trial of
> the Stable Release/LTS policy to determine what are the best working practices
> for DPDK.
> 
> The maintainer for the initial release will be Yuanhan Liu
> <yuanhan.liu@linux.intel.com>. It is hoped that other community members will
> volunteer as maintainers for other Stable Releases.
> 
> The initial targeted release for LTS is proposed to be 16.11 based on the
> results of the work carried out on the 16.07 Stable Release.
> 
> A list has been set up for Stable Release/LTS specific discussions:
> <stable@dpdk.org>. This address can also be used for CCing maintainers on bug
> fix submissions.

Yes, we could use this mailing list for that. But it's slightly
different from what I proposed in the first time:

For each bug fix patch that need be backported to a stable branch,
it's suggested to add following line in the commit log, just before
your Signed-off-by:

   Cc: <stable@dpdk.org>

So that this patch will be cc'ed to the stable mailing list; this
is an explicit sign to tell the stable maintainers, "hey, there
is a candidate for a stable release. Please review and consider
merge it".

If we have several stable branches later and a patch just applies
to a specific branch, it could be:

    Cc: v16.07 <stable@dpdk.org>

And we should doc this at page http://dpdk.org/dev.

	--yliu

Re: [dpdk-dev] DPDK Stable Releases and Long Term Support

[Panu Matilainen]

[ Yes I'm late to this party, apologies for missing the first round of 
discussion ]

On 07/28/2016 03:33 PM, Mcnamara, John wrote:
>
> This document sets out the guidelines for DPDK Stable Releases and Long Term
> Support releases (LTS) based on the initial RFC and comments:
> http://dpdk.org/ml/archives/dev/2016-June/040256.html.
>
> In particular it incorporates suggestions for a Stable Release structure as
> well as a Long Term Support release.
>
>
> Introduction
> ------------
>
> The purpose of the DPDK Stable Releases will be to maintain releases of DPDK
> with backported fixes over an extended period of time. This will provide
> downstream consumers of DPDK with a stable target on which to base
> applications or packages.
>
> The Long Term Support release (LTS) will be a designation applied to a Stable
> Release to indicate longer 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 will be used to backport fixes from a N release back to a N-1
> release, for example, from 16.11 to 16.07.
>
> The duration of a stable release should be one complete release cycle. 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 can be determined by the maintainer based on the number of
> bugfixes and the criticality of the bugs. However, 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.
>
> It is anticipated that there should 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.
>
>
> Initial Stable Release
> ----------------------
>
> The initial DPDK Stable Release will be 16.07. It will be viewed as a trial of
> the Stable Release/LTS policy to determine what are the best working practices
> for DPDK.
>
> The maintainer for the initial release will be Yuanhan Liu
> <yuanhan.liu@linux.intel.com>. It is hoped that other community members will
> volunteer as maintainers for other Stable Releases.
>
> The initial targeted release for LTS is proposed to be 16.11 based on the
> results of the work carried out on the 16.07 Stable Release.
>
> A list has been set up for Stable Release/LTS specific discussions:
> <stable@dpdk.org>. This address can also be used for CCing maintainers on bug
> fix submissions.
>
>
> What changes should be backported
> ---------------------------------
>
> The 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.

A new PMD also would not touch existing code, which makes it a 
low-to-no-risk thing. Ditto for, say, new command line tool or an example.

> * The work of preparing the backport is done by the proposer.
> * There is support within the community.
>
>
> Testing
> -------
>
> Stable and LTS releases should be tested before release/tagging.
>
> Intel will provide validation engineers to test the 16.07 Stable Release and
> the initial LTS tree. Other community members should provide testing for other
> stable releases.
>
> The validation will consist of compilation testing on the range of OSes
> supported by the master release and functional/performance testing on the
> current major/LTS release of the following OSes:
>
> * Ubuntu
> * RHEL
> * SuSE
> * FreeBSD
>
>
> Releasing
> ---------
>
> A Stable Release will be released by:
>
> * Tagging the release with YY.MM.nn (year, month, number) or similar.
> * Uploading a tarball of the release to dpdk.org.
> * Sending an announcement to the <announce@dpdk.org> list.
>
>
> ABI
> ---
>
> The Stable Release should not be seen as a way of breaking or circumventing
> the DPDK ABI policy.

I find this a strange thing to say about a stable/LTS release ABI. I had 
read the originating thread before seeing this, but it still made me go 
"Huh?" for several seconds. The problem perhaps being, the rest of the 
document addresses stable/LTS releases, but this statement speaks about 
normal development work going on elsewhere.

The earlier version had a mention about ABI/API breakage related to 
things what not to backport but that's entirely gone here. Given how 
important ABI + API stability is for stable/LTS releases, I think it 
deserves a special mention here. Maybe something more to the tune of:

---
ABI or API breakages are not permitted in stable releases, special care 
must be taken to when backporting.

The existence of stable release(s) does not lessen the need to comply to 
DPDK ABI policy in development work.
---

>
>
> Review of the Stable Release/LTS guidelines
> -------------------------------------------
>
> This document serves as a set of guidelines for the planned Stable
> Releases/LTS activities. However, the actual process can be reviewed and
> amended over time, based on experiences and feedback.
>

With the exception of the ABI/API thing, this looks like a fair starting 
point to me. Time and experience will tell more.

	 - Panu -

Re: [dpdk-dev] DPDK Stable Releases and Long Term Support

[Mcnamara, John]

> -----Original Message-----
> From: Panu Matilainen [mailto:pmatilai@redhat.com]
> Sent: Wednesday, August 17, 2016 1:30 PM
> To: Mcnamara, John <john.mcnamara@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] DPDK Stable Releases and Long Term Support
> 
> ...
>
> > ABI
> > ---
> >
> > The Stable Release should not be seen as a way of breaking or
> > circumventing the DPDK ABI policy.
> 
> I find this a strange thing to say about a stable/LTS release ABI. I had
> read the originating thread before seeing this, but it still made me go
> "Huh?" for several seconds. The problem perhaps being, the rest of the
> document addresses stable/LTS releases, but this statement speaks about
> normal development work going on elsewhere.
> 
> The earlier version had a mention about ABI/API breakage related to things
> what not to backport but that's entirely gone here. Given how important
> ABI + API stability is for stable/LTS releases, I think it deserves a
> special mention here. Maybe something more to the tune of:
> 
> ---
> ABI or API breakages are not permitted in stable releases, special care
> must be taken to when backporting.
> 
> The existence of stable release(s) does not lessen the need to comply to
> DPDK ABI policy in development work.
> ---

That seems reasonable. If I do an update to the doc or add it to the guides I'll update it with this.

> 
> With the exception of the ABI/API thing, this looks like a fair starting
> point to me. Time and experience will tell more.
> 

I also think that we will have to see how it goes. What is important is that we end up with something that is useful to the community and consumers.

John.
--