[dpdk-web] [PATCH] update stable releases roadmap

[dpdk-web] [PATCH] update stable releases roadmap

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

---
This is at the same time, a call for volunteer,
and a proposed change to shorten the wait for the first stable releases
from at least 3 months to 2 months.

Let's add this discussion to the agenda of the next techboard meeting.
---
 dev/roadmap.html | 35 +++++++++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/dev/roadmap.html b/dev/roadmap.html
index e6cf640..e40f410 100644
--- a/dev/roadmap.html
+++ b/dev/roadmap.html
@@ -104,6 +104,8 @@
 		<li>Release: November 2, 2018
 	</ul>
 	<h2 id="stable">Stable releases</h2>
+	<p>There is a documentation page describing the
+	<a href="/doc/guides/contributing/stable.html">guidelines of the stable releases</a>.
 	<p>Stable point releases follow mainline releases.
 	<p>After each -rc tag and after the final version, relevant bug fixes get
 	backported by the stable maintainers into the respective branches in "bursts".
@@ -111,8 +113,9 @@
 	to stable@dpdk.org only (avoiding dev@dpdk.org).
 	<p>After all the relevant bugfixes have been backported,
 	regression tests are ran, and if clear, the stable release is announced.
-	<p>Typically a new stable release version follows a mainline release
-	by 1-2 weeks, depending on the test results.
+	<p>The first stable release (.1) of a branch should follow
+	its mainline release (.0) by two months,
+	before starting tests of the next mainline release candidates.
 	<hr>
 	<div style="overflow-x:auto">
 	<table>
@@ -125,15 +128,39 @@
 		<tr>
 			<td>16.11.6</td>
 			<td>May 19, 2018</td>
-			<td>November 2018</td>
+			<td>November 2018 (LTS)</td>
 			<td>Luca Boccassi</td>
 		</tr>
 		<tr>
 			<td>17.11.2</td>
 			<td>May 19, 2018</td>
-			<td>November 2019</td>
+			<td>November 2019 (LTS)</td>
 			<td>Yuanhan Liu</td>
 		</tr>
+		<tr>
+			<td>18.02.1</td>
+			<td>April 6, 2018</td>
+			<td>June 2018</td>
+			<td>looking for volunteer</td>
+		</tr>
+		<tr>
+			<td>18.05.1</td>
+			<td>June 29, 2018</td>
+			<td>October 2018</td>
+			<td>looking for volunteer</td>
+		</tr>
+		<tr>
+			<td>18.08.1</td>
+			<td>October 5, 2018</td>
+			<td>January 2019</td>
+			<td>looking for volunteer</td>
+		</tr>
+		<tr>
+			<td>18.11.1</td>
+			<td>January 11, 2019</td>
+			<td>November 2020 (LTS)</td>
+			<td>looking for volunteer</td>
+		</tr>
 	</table>
 	</div>
 </section>
-- 
2.16.2

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Luca Boccassi]

On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> 
> ---
> This is at the same time, a call for volunteer,
> and a proposed change to shorten the wait for the first stable
> releases
> from at least 3 months to 2 months.
> 
> Let's add this discussion to the agenda of the next techboard
> meeting.

The issue is how to decide what goes into a stable release, if it does
not follow a main release.

Right now we follow the main release as that means there is a list of
accepted and merged commits that can be backported - if the stable
release is anticipated, what is going to be backported?

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Thomas Monjalon]

09/03/2018 14:44, Luca Boccassi:
> On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > 
> > ---
> > This is at the same time, a call for volunteer,
> > and a proposed change to shorten the wait for the first stable
> > releases
> > from at least 3 months to 2 months.
> > 
> > Let's add this discussion to the agenda of the next techboard
> > meeting.
> 
> The issue is how to decide what goes into a stable release, if it does
> not follow a main release.
> 
> Right now we follow the main release as that means there is a list of
> accepted and merged commits that can be backported - if the stable
> release is anticipated, what is going to be backported?

If we pull patches more regularly in master, there can be a lot of fixes
accumulated during 2 months.

Re: [dpdk-web] [dpdk-techboard] [PATCH] update stable releases roadmap

[Ananyev, Konstantin]

> -----Original Message-----
> From: techboard [mailto:techboard-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, March 9, 2018 1:49 PM
> To: Luca Boccassi <bluca@debian.org>
> Cc: web@dpdk.org; yliu@fridaylinux.org; ktraynor@redhat.com; techboard@dpdk.org
> Subject: Re: [dpdk-techboard] [dpdk-web] [PATCH] update stable releases roadmap
> 
> 09/03/2018 14:44, Luca Boccassi:
> > On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > >
> > > ---
> > > This is at the same time, a call for volunteer,
> > > and a proposed change to shorten the wait for the first stable
> > > releases
> > > from at least 3 months to 2 months.
> > >
> > > Let's add this discussion to the agenda of the next techboard
> > > meeting.
> >
> > The issue is how to decide what goes into a stable release, if it does
> > not follow a main release.
> >
> > Right now we follow the main release as that means there is a list of
> > accepted and merged commits that can be backported - if the stable
> > release is anticipated, what is going to be backported?
> 
> If we pull patches more regularly in master, there can be a lot of fixes
> accumulated during 2 months.

But these patches need to be properly tested before going into LTS, right?
So it means extra effort for the validation teams?
Konstantin


 

Re: [dpdk-web] [dpdk-techboard] [PATCH] update stable releases roadmap

[Thomas Monjalon]

09/03/2018 15:03, Ananyev, Konstantin:
> From: Thomas Monjalon
> > 09/03/2018 14:44, Luca Boccassi:
> > > On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> > > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > > >
> > > > ---
> > > > This is at the same time, a call for volunteer,
> > > > and a proposed change to shorten the wait for the first stable
> > > > releases
> > > > from at least 3 months to 2 months.
> > > >
> > > > Let's add this discussion to the agenda of the next techboard
> > > > meeting.
> > >
> > > The issue is how to decide what goes into a stable release, if it does
> > > not follow a main release.
> > >
> > > Right now we follow the main release as that means there is a list of
> > > accepted and merged commits that can be backported - if the stable
> > > release is anticipated, what is going to be backported?
> > 
> > If we pull patches more regularly in master, there can be a lot of fixes
> > accumulated during 2 months.
> 
> But these patches need to be properly tested before going into LTS, right?
> So it means extra effort for the validation teams?

Exact
The stable release must be validated anyway.
The proposal is to validate the .1 release before starting RC1 validation,
instead of doing it after the .0 release.

Re: [dpdk-web] [dpdk-techboard] [PATCH] update stable releases roadmap

[Ferruh Yigit]

On 3/9/2018 2:19 PM, Thomas Monjalon wrote:
> 09/03/2018 15:03, Ananyev, Konstantin:
>> From: Thomas Monjalon
>>> 09/03/2018 14:44, Luca Boccassi:
>>>> On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
>>>>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>>>>>
>>>>> ---
>>>>> This is at the same time, a call for volunteer,
>>>>> and a proposed change to shorten the wait for the first stable
>>>>> releases
>>>>> from at least 3 months to 2 months.
>>>>>
>>>>> Let's add this discussion to the agenda of the next techboard
>>>>> meeting.
>>>>
>>>> The issue is how to decide what goes into a stable release, if it does
>>>> not follow a main release.
>>>>
>>>> Right now we follow the main release as that means there is a list of
>>>> accepted and merged commits that can be backported - if the stable
>>>> release is anticipated, what is going to be backported?
>>>
>>> If we pull patches more regularly in master, there can be a lot of fixes
>>> accumulated during 2 months.
>>
>> But these patches need to be properly tested before going into LTS, right?
>> So it means extra effort for the validation teams?
> 
> Exact
> The stable release must be validated anyway.
> The proposal is to validate the .1 release before starting RC1 validation,
> instead of doing it after the .0 release.

I have same concern with Konstantin.

Why merging unverified patches to the stable tree? It is not uncommon that we
fix fixes during rc phase.

I am for waiting proper release to backport fixes to the stable release.

For specific cases, like backporting a specific hot fixes to the stable, I
understand having stable release before actual release, but for that case the
scope and what to focus/test is limited and can be managed.

Is there a request received to get stable trees earlier? What is the motivation
of the change?

Re: [dpdk-web] [dpdk-techboard] [PATCH] update stable releases roadmap

[Thomas Monjalon]

09/03/2018 16:24, Ferruh Yigit:
> On 3/9/2018 2:19 PM, Thomas Monjalon wrote:
> > 09/03/2018 15:03, Ananyev, Konstantin:
> >> From: Thomas Monjalon
> >>> 09/03/2018 14:44, Luca Boccassi:
> >>>> On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> >>>>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >>>>>
> >>>>> ---
> >>>>> This is at the same time, a call for volunteer,
> >>>>> and a proposed change to shorten the wait for the first stable
> >>>>> releases
> >>>>> from at least 3 months to 2 months.
> >>>>>
> >>>>> Let's add this discussion to the agenda of the next techboard
> >>>>> meeting.
> >>>>
> >>>> The issue is how to decide what goes into a stable release, if it does
> >>>> not follow a main release.
> >>>>
> >>>> Right now we follow the main release as that means there is a list of
> >>>> accepted and merged commits that can be backported - if the stable
> >>>> release is anticipated, what is going to be backported?
> >>>
> >>> If we pull patches more regularly in master, there can be a lot of fixes
> >>> accumulated during 2 months.
> >>
> >> But these patches need to be properly tested before going into LTS, right?
> >> So it means extra effort for the validation teams?
> > 
> > Exact
> > The stable release must be validated anyway.
> > The proposal is to validate the .1 release before starting RC1 validation,
> > instead of doing it after the .0 release.
> 
> I have same concern with Konstantin.
> 
> Why merging unverified patches to the stable tree? It is not uncommon that we
> fix fixes during rc phase.
> 
> I am for waiting proper release to backport fixes to the stable release.

It is a valid concern.

> For specific cases, like backporting a specific hot fixes to the stable, I
> understand having stable release before actual release, but for that case the
> scope and what to focus/test is limited and can be managed.
> 
> Is there a request received to get stable trees earlier? What is the motivation
> of the change?

When a bug is found just after a major release .0, we must wait the next
major release to get it fixed in a release. I find it frustrating.
My thought is that the stable branch should help between two major releases.
If not releasing .1 between two major releases, we could at least
update the branch more regularly. It is currently a burst 2 weeks
before releasing the stable version, i.e. after the new major release
which already contains all the new fixes.

Some companies do not rely on the stable branches for the support of their
customers because the patches are applied too late. It is a pity.
It is OK that companies have their own backport with different risks
and priorities considerations. But we should try to have a common
community basis of backports without waiting 3 months.

The other concern is how to spread the validation efforts of the
main and stable releases over the year without overlaps.

Re: [dpdk-web] [dpdk-techboard] [PATCH] update stable releases roadmap

[Luca Boccassi]

On Fri, 2018-03-09 at 16:45 +0100, Thomas Monjalon wrote:
> 09/03/2018 16:24, Ferruh Yigit:
> > On 3/9/2018 2:19 PM, Thomas Monjalon wrote:
> > > 09/03/2018 15:03, Ananyev, Konstantin:
> > > > From: Thomas Monjalon
> > > > > 09/03/2018 14:44, Luca Boccassi:
> > > > > > On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> > > > > > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > 
> > > > > > > ---
> > > > > > > This is at the same time, a call for volunteer,
> > > > > > > and a proposed change to shorten the wait for the first
> > > > > > > stable
> > > > > > > releases
> > > > > > > from at least 3 months to 2 months.
> > > > > > > 
> > > > > > > Let's add this discussion to the agenda of the next
> > > > > > > techboard
> > > > > > > meeting.
> > > > > > 
> > > > > > The issue is how to decide what goes into a stable release,
> > > > > > if it does
> > > > > > not follow a main release.
> > > > > > 
> > > > > > Right now we follow the main release as that means there is
> > > > > > a list of
> > > > > > accepted and merged commits that can be backported - if the
> > > > > > stable
> > > > > > release is anticipated, what is going to be backported?
> > > > > 
> > > > > If we pull patches more regularly in master, there can be a
> > > > > lot of fixes
> > > > > accumulated during 2 months.
> > > > 
> > > > But these patches need to be properly tested before going into
> > > > LTS, right?
> > > > So it means extra effort for the validation teams?
> > > 
> > > Exact
> > > The stable release must be validated anyway.
> > > The proposal is to validate the .1 release before starting RC1
> > > validation,
> > > instead of doing it after the .0 release.
> > 
> > I have same concern with Konstantin.
> > 
> > Why merging unverified patches to the stable tree? It is not
> > uncommon that we
> > fix fixes during rc phase.
> > 
> > I am for waiting proper release to backport fixes to the stable
> > release.
> 
> It is a valid concern.
> 
> > For specific cases, like backporting a specific hot fixes to the
> > stable, I
> > understand having stable release before actual release, but for
> > that case the
> > scope and what to focus/test is limited and can be managed.
> > 
> > Is there a request received to get stable trees earlier? What is
> > the motivation
> > of the change?
> 
> When a bug is found just after a major release .0, we must wait the
> next
> major release to get it fixed in a release. I find it frustrating.
> My thought is that the stable branch should help between two major
> releases.
> If not releasing .1 between two major releases, we could at least
> update the branch more regularly. It is currently a burst 2 weeks
> before releasing the stable version, i.e. after the new major release
> which already contains all the new fixes.
> 
> Some companies do not rely on the stable branches for the support of
> their
> customers because the patches are applied too late. It is a pity.
> It is OK that companies have their own backport with different risks
> and priorities considerations. But we should try to have a common
> community basis of backports without waiting 3 months.
> 
> The other concern is how to spread the validation efforts of the
> main and stable releases over the year without overlaps.

I am OK with doing more stable releases for 16.11 depending on specific
bug fixes that are important enough - but I think it should be in
addition to the releases that we do after a mainline release, and for
specific and well-tested individual fixes, rather than for everything
that was merged before RC1, as I believe it's too risky, for the same
reasons that Ferruh mentioned.

It should also be dependent on the companies providing regression tests
(currently Intel and AT&T for 16.11) being available to commit the
additional time, or for some other company to provide similar QA
resources.

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Kevin Traynor]

hi Thomas,

On 03/09/2018 01:36 PM, Thomas Monjalon wrote:
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> 
> ---
> This is at the same time, a call for volunteer,
> and a proposed change to shorten the wait for the first stable releases
> from at least 3 months to 2 months.
> 
> Let's add this discussion to the agenda of the next techboard meeting.
> ---
>  dev/roadmap.html | 35 +++++++++++++++++++++++++++++++----
>  1 file changed, 31 insertions(+), 4 deletions(-)
> 
> diff --git a/dev/roadmap.html b/dev/roadmap.html
> index e6cf640..e40f410 100644
> --- a/dev/roadmap.html
> +++ b/dev/roadmap.html
> @@ -104,6 +104,8 @@
>  		<li>Release: November 2, 2018
>  	</ul>
>  	<h2 id="stable">Stable releases</h2>
> +	<p>There is a documentation page describing the
> +	<a href="/doc/guides/contributing/stable.html">guidelines of the stable releases</a>.
>  	<p>Stable point releases follow mainline releases.
>  	<p>After each -rc tag and after the final version, relevant bug fixes get
>  	backported by the stable maintainers into the respective branches in "bursts".
> @@ -111,8 +113,9 @@
>  	to stable@dpdk.org only (avoiding dev@dpdk.org).
>  	<p>After all the relevant bugfixes have been backported,
>  	regression tests are ran, and if clear, the stable release is announced.
> -	<p>Typically a new stable release version follows a mainline release
> -	by 1-2 weeks, depending on the test results.
> +	<p>The first stable release (.1) of a branch should follow
> +	its mainline release (.0) by two months,
> +	before starting tests of the next mainline release candidates.
>  	<hr>
>  	<div style="overflow-x:auto">
>  	<table>
> @@ -125,15 +128,39 @@
>  		<tr>
>  			<td>16.11.6</td>
>  			<td>May 19, 2018</td>
> -			<td>November 2018</td>
> +			<td>November 2018 (LTS)</td>
>  			<td>Luca Boccassi</td>
>  		</tr>
>  		<tr>
>  			<td>17.11.2</td>
>  			<td>May 19, 2018</td>
> -			<td>November 2019</td>
> +			<td>November 2019 (LTS)</td>
>  			<td>Yuanhan Liu</td>
>  		</tr>
> +		<tr>
> +			<td>18.02.1</td>
> +			<td>April 6, 2018</td>
> +			<td>June 2018</td>
> +			<td>looking for volunteer</td>
> +		</tr>
> +		<tr>
> +			<td>18.05.1</td>
> +			<td>June 29, 2018</td>
> +			<td>October 2018</td>
> +			<td>looking for volunteer</td>
> +		</tr>
> +		<tr>
> +			<td>18.08.1</td>
> +			<td>October 5, 2018</td>
> +			<td>January 2019</td>
> +			<td>looking for volunteer</td>
> +		</tr>
> +		<tr>
> +			<td>18.11.1</td>
> +			<td>January 11, 2019</td>
> +			<td>November 2020 (LTS)</td>
> +			<td>looking for volunteer</td>

I am available to volunteer for 18.11 :-)

thanks,
Kevin.

> +		</tr>
>  	</table>
>  	</div>
>  </section>
> 

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Thomas Monjalon]

Hi Kevin,

09/03/2018 15:30, Kevin Traynor:
> hi Thomas,
> 
> On 03/09/2018 01:36 PM, Thomas Monjalon wrote:
> > +			<td>18.11.1</td>
> > +			<td>January 11, 2019</td>
> > +			<td>November 2020 (LTS)</td>
> > +			<td>looking for volunteer</td>
> 
> I am available to volunteer for 18.11 :-)

Thanks a lot, I will add your name when approved
by the Technical Board.

Any time available to experience stable releases
with non-LTS 18.05.x during the summer?

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Kevin Traynor]

On 03/09/2018 02:51 PM, Thomas Monjalon wrote:
> Hi Kevin,
> 
> 09/03/2018 15:30, Kevin Traynor:
>> hi Thomas,
>>
>> On 03/09/2018 01:36 PM, Thomas Monjalon wrote:
>>> +			<td>18.11.1</td>
>>> +			<td>January 11, 2019</td>
>>> +			<td>November 2020 (LTS)</td>
>>> +			<td>looking for volunteer</td>
>>
>> I am available to volunteer for 18.11 :-)
> 
> Thanks a lot, I will add your name when approved
> by the Technical Board.
> 

Sure, thanks

> Any time available to experience stable releases
> with non-LTS 18.05.x during the summer?
> 

Sorry, I can't commit for it because lack of bandwidth between work and
holidays

> 

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Luca Boccassi]

On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> 
> ---
> This is at the same time, a call for volunteer,
> and a proposed change to shorten the wait for the first stable
> releases
> from at least 3 months to 2 months.
> 
> Let's add this discussion to the agenda of the next techboard
> meeting.
> ---
>  dev/roadmap.html | 35 +++++++++++++++++++++++++++++++----
>  1 file changed, 31 insertions(+), 4 deletions(-)
> 
> diff --git a/dev/roadmap.html b/dev/roadmap.html
> index e6cf640..e40f410 100644
> --- a/dev/roadmap.html
> +++ b/dev/roadmap.html
> @@ -104,6 +104,8 @@
>  		<li>Release: November 2, 2018
>  	</ul>
>  	<h2 id="stable">Stable releases</h2>
> +	<p>There is a documentation page describing the
> +	<a href="/doc/guides/contributing/stable.html">guidelines of
> the stable releases</a>.
>  	<p>Stable point releases follow mainline releases.
>  	<p>After each -rc tag and after the final version, relevant
> bug fixes get
>  	backported by the stable maintainers into the respective
> branches in "bursts".
> @@ -111,8 +113,9 @@
>  	to stable@dpdk.org only (avoiding dev@dpdk.org).
>  	<p>After all the relevant bugfixes have been backported,
>  	regression tests are ran, and if clear, the stable release
> is announced.
> -	<p>Typically a new stable release version follows a mainline
> release
> -	by 1-2 weeks, depending on the test results.
> +	<p>The first stable release (.1) of a branch should follow
> +	its mainline release (.0) by two months,
> +	before starting tests of the next mainline release
> candidates.
>  	<hr>
>  	<div style="overflow-x:auto">
>  	<table>
> @@ -125,15 +128,39 @@
>  		<tr>
>  			<td>16.11.6</td>
>  			<td>May 19, 2018</td>
> -			<td>November 2018</td>
> +			<td>November 2018 (LTS)</td>
>  			<td>Luca Boccassi</td>
>  		</tr>
>  		<tr>
>  			<td>17.11.2</td>
>  			<td>May 19, 2018</td>
> -			<td>November 2019</td>
> +			<td>November 2019 (LTS)</td>
>  			<td>Yuanhan Liu</td>
>  		</tr>
> +		<tr>
> +			<td>18.02.1</td>
> +			<td>April 6, 2018</td>
> +			<td>June 2018</td>
> +			<td>looking for volunteer</td>
> +		</tr>
> +		<tr>
> +			<td>18.05.1</td>
> +			<td>June 29, 2018</td>
> +			<td>October 2018</td>
> +			<td>looking for volunteer</td>
> +		</tr>
> +		<tr>
> +			<td>18.08.1</td>
> +			<td>October 5, 2018</td>
> +			<td>January 2019</td>
> +			<td>looking for volunteer</td>
> +		</tr>
> +		<tr>
> +			<td>18.11.1</td>
> +			<td>January 11, 2019</td>
> +			<td>November 2020 (LTS)</td>
> +			<td>looking for volunteer</td>
> +		</tr>
>  	</table>
>  	</div>
>  </section>

Hi,

I'm happy to help with 18.02.1.

Given it will be based on 18.05-rc2, which is due out on approximately
April 20th, I think we can be ambitious and target April 27th as the
tentative release date.

Note that ATT won't be able to help with regression tests this time
around. John, may we count on help from Intel to run the usual batch of
regression tests between the 20th and the 27th?

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Luca Boccassi]

On Thu, 2018-03-22 at 11:03 +0000, Luca Boccassi wrote:
> On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > 
> > ---
> > This is at the same time, a call for volunteer,
> > and a proposed change to shorten the wait for the first stable
> > releases
> > from at least 3 months to 2 months.
> > 
> > Let's add this discussion to the agenda of the next techboard
> > meeting.
> > ---
> >  dev/roadmap.html | 35 +++++++++++++++++++++++++++++++----
> >  1 file changed, 31 insertions(+), 4 deletions(-)
> > 
> > diff --git a/dev/roadmap.html b/dev/roadmap.html
> > index e6cf640..e40f410 100644
> > --- a/dev/roadmap.html
> > +++ b/dev/roadmap.html
> > @@ -104,6 +104,8 @@
> >  		<li>Release: November 2, 2018
> >  	</ul>
> >  	<h2 id="stable">Stable releases</h2>
> > +	<p>There is a documentation page describing the
> > +	<a href="/doc/guides/contributing/stable.html">guidelines
> > of
> > the stable releases</a>.
> >  	<p>Stable point releases follow mainline releases.
> >  	<p>After each -rc tag and after the final version,
> > relevant
> > bug fixes get
> >  	backported by the stable maintainers into the respective
> > branches in "bursts".
> > @@ -111,8 +113,9 @@
> >  	to stable@dpdk.org only (avoiding dev@dpdk.org).
> >  	<p>After all the relevant bugfixes have been backported,
> >  	regression tests are ran, and if clear, the stable release
> > is announced.
> > -	<p>Typically a new stable release version follows a
> > mainline
> > release
> > -	by 1-2 weeks, depending on the test results.
> > +	<p>The first stable release (.1) of a branch should follow
> > +	its mainline release (.0) by two months,
> > +	before starting tests of the next mainline release
> > candidates.
> >  	<hr>
> >  	<div style="overflow-x:auto">
> >  	<table>
> > @@ -125,15 +128,39 @@
> >  		<tr>
> >  			<td>16.11.6</td>
> >  			<td>May 19, 2018</td>
> > -			<td>November 2018</td>
> > +			<td>November 2018 (LTS)</td>
> >  			<td>Luca Boccassi</td>
> >  		</tr>
> >  		<tr>
> >  			<td>17.11.2</td>
> >  			<td>May 19, 2018</td>
> > -			<td>November 2019</td>
> > +			<td>November 2019 (LTS)</td>
> >  			<td>Yuanhan Liu</td>
> >  		</tr>
> > +		<tr>
> > +			<td>18.02.1</td>
> > +			<td>April 6, 2018</td>
> > +			<td>June 2018</td>
> > +			<td>looking for volunteer</td>
> > +		</tr>
> > +		<tr>
> > +			<td>18.05.1</td>
> > +			<td>June 29, 2018</td>
> > +			<td>October 2018</td>
> > +			<td>looking for volunteer</td>
> > +		</tr>
> > +		<tr>
> > +			<td>18.08.1</td>
> > +			<td>October 5, 2018</td>
> > +			<td>January 2019</td>
> > +			<td>looking for volunteer</td>
> > +		</tr>
> > +		<tr>
> > +			<td>18.11.1</td>
> > +			<td>January 11, 2019</td>
> > +			<td>November 2020 (LTS)</td>
> > +			<td>looking for volunteer</td>
> > +		</tr>
> >  	</table>
> >  	</div>
> >  </section>
> 
> Hi,
> 
> I'm happy to help with 18.02.1.
> 
> Given it will be based on 18.05-rc2, which is due out on
> approximately
> April 20th, I think we can be ambitious and target April 27th as the
> tentative release date.
> 
> Note that ATT won't be able to help with regression tests this time
> around. John, may we count on help from Intel to run the usual batch
> of
> regression tests between the 20th and the 27th?

Slight misunderstanding, sorry - we'll want to base 18.02.1 on 18.05-
rc1 (not rc2), which means the dates get pulled forward by 10 days -
I'll make the branch available for review and eventually ask for help
from backporters if needed on April the 10th, and ambitiously targeting
release for April the 17th.
So we'd need regression tests done before the 17th of April.

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Thomas Monjalon]

22/03/2018 12:03, Luca Boccassi:
> Hi,
> 
> I'm happy to help with 18.02.1.

Thanks a lot.
For next stable branches, we must find more volunteers.

> Given it will be based on 18.05-rc2, which is due out on approximately
> April 20th, I think we can be ambitious and target April 27th as the
> tentative release date.

I think 18.02.1 should be based on 18.05-rc1, so April 20th would be
a tentative release date for 18.02.1 (before 18.05-rc2).
I will send a v2 of this schedule.

> Note that ATT won't be able to help with regression tests this time
> around. John, may we count on help from Intel to run the usual batch of
> regression tests between the 20th and the 27th?

Or one week before :)

It would be good to have more companies involved in testing stable releases.
We need to explicitly ask to some of the members. Can be done privately.

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Christian Ehrhardt]

Hi,
Luca made me aware of this - thanks!

In reference to [1], I'd volunteer for 18.05.1

I was not subscribed before this, so I hope replying to the forwarded mail
gets the threading right.

[1]: http://dpdk.org/ml/archives/web/2018-March/000615.html


On Thu, Apr 5, 2018 at 4:16 PM, Luca Boccassi <bluca@debian.org> wrote:

> On Fri, 2018-03-09 at 14:36 +0100, Thomas Monjalon wrote:
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >
> > ---
> > This is at the same time, a call for volunteer,
> > and a proposed change to shorten the wait for the first stable
> > releases
> > from at least 3 months to 2 months.
> >
> > Let's add this discussion to the agenda of the next techboard
> > meeting.
> > ---
> >  dev/roadmap.html | 35 +++++++++++++++++++++++++++++++----
> >  1 file changed, 31 insertions(+), 4 deletions(-)
> >
> > diff --git a/dev/roadmap.html b/dev/roadmap.html
> > index e6cf640..e40f410 100644
> > --- a/dev/roadmap.html
> > +++ b/dev/roadmap.html
> > @@ -104,6 +104,8 @@
> >               <li>Release: November 2, 2018
> >       </ul>
> >       <h2 id="stable">Stable releases</h2>
> > +     <p>There is a documentation page describing the
> > +     <a href="/doc/guides/contributing/stable.html">guidelines of
> > the stable releases</a>.
> >       <p>Stable point releases follow mainline releases.
> >       <p>After each -rc tag and after the final version, relevant
> > bug fixes get
> >       backported by the stable maintainers into the respective
> > branches in "bursts".
> > @@ -111,8 +113,9 @@
> >       to stable@dpdk.org only (avoiding dev@dpdk.org).
> >       <p>After all the relevant bugfixes have been backported,
> >       regression tests are ran, and if clear, the stable release
> > is announced.
> > -     <p>Typically a new stable release version follows a mainline
> > release
> > -     by 1-2 weeks, depending on the test results.
> > +     <p>The first stable release (.1) of a branch should follow
> > +     its mainline release (.0) by two months,
> > +     before starting tests of the next mainline release
> > candidates.
> >       <hr>
> >       <div style="overflow-x:auto">
> >       <table>
> > @@ -125,15 +128,39 @@
> >               <tr>
> >                       <td>16.11.6</td>
> >                       <td>May 19, 2018</td>
> > -                     <td>November 2018</td>
> > +                     <td>November 2018 (LTS)</td>
> >                       <td>Luca Boccassi</td>
> >               </tr>
> >               <tr>
> >                       <td>17.11.2</td>
> >                       <td>May 19, 2018</td>
> > -                     <td>November 2019</td>
> > +                     <td>November 2019 (LTS)</td>
> >                       <td>Yuanhan Liu</td>
> >               </tr>
> > +             <tr>
> > +                     <td>18.02.1</td>
> > +                     <td>April 6, 2018</td>
> > +                     <td>June 2018</td>
> > +                     <td>looking for volunteer</td>
> > +             </tr>
> > +             <tr>
> > +                     <td>18.05.1</td>
> > +                     <td>June 29, 2018</td>
> > +                     <td>October 2018</td>
> > +                     <td>looking for volunteer</td>
> > +             </tr>
> > +             <tr>
> > +                     <td>18.08.1</td>
> > +                     <td>October 5, 2018</td>
> > +                     <td>January 2019</td>
> > +                     <td>looking for volunteer</td>
> > +             </tr>
> > +             <tr>
> > +                     <td>18.11.1</td>
> > +                     <td>January 11, 2019</td>
> > +                     <td>November 2020 (LTS)</td>
> > +                     <td>looking for volunteer</td>
> > +             </tr>
> >       </table>
> >       </div>
> >  </section>
>
> --
> Kind regards,
> Luca Boccassi




-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [dpdk-web] [PATCH] update stable releases roadmap

[Thomas Monjalon]

05/04/2018 16:19, Christian Ehrhardt:
> Hi,
> Luca made me aware of this - thanks!
> 
> In reference to [1], I'd volunteer for 18.05.1

Thanks a lot Christian.
It's good to have downstream users as stable maintainers.

> I was not subscribed before this, so I hope replying to the forwarded mail
> gets the threading right.

No :)
I should have Cc dev@dpdk.org. Will do for v2.

> [1]: http://dpdk.org/ml/archives/web/2018-March/000615.html

[dpdk-web] [PATCH v2] update stable releases roadmap

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
Patch for the website (to web@dpdk.org) Cc'ed to dev@dpdk.org

v2:
	- more volunteers
	- propose to do .1 release after -rc1 of next branch.

---
 dev/roadmap.html | 37 ++++++++++++++++++++++++++++++++-----
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/dev/roadmap.html b/dev/roadmap.html
index e6cf640..c7cd7cb 100644
--- a/dev/roadmap.html
+++ b/dev/roadmap.html
@@ -97,13 +97,15 @@
 		<li>Integration deadline: June 29, 2018
 		<li>Release: August 1, 2018
 	</ul>
-	<p>18.11
+	<p>18.11 (LTS)
 	<ul>
 		<li>Proposal deadline: September 7, 2018
 		<li>Integration deadline: October 5, 2018
 		<li>Release: November 2, 2018
 	</ul>
 	<h2 id="stable">Stable releases</h2>
+	<p>There is a documentation page describing the
+	<a href="/doc/guides/contributing/stable.html">guidelines of the stable releases</a>.
 	<p>Stable point releases follow mainline releases.
 	<p>After each -rc tag and after the final version, relevant bug fixes get
 	backported by the stable maintainers into the respective branches in "bursts".
@@ -111,8 +113,9 @@
 	to stable@dpdk.org only (avoiding dev@dpdk.org).
 	<p>After all the relevant bugfixes have been backported,
 	regression tests are ran, and if clear, the stable release is announced.
-	<p>Typically a new stable release version follows a mainline release
-	by 1-2 weeks, depending on the test results.
+	<p>The first stable release (.1) of a branch should follow
+	its mainline release (.0) by at least two months,
+	after the first release candidate (-rc1) of the next branch.
 	<hr>
 	<div style="overflow-x:auto">
 	<table>
@@ -125,15 +128,39 @@
 		<tr>
 			<td>16.11.6</td>
 			<td>May 19, 2018</td>
-			<td>November 2018</td>
+			<td>November 2018 (LTS)</td>
 			<td>Luca Boccassi</td>
 		</tr>
 		<tr>
 			<td>17.11.2</td>
 			<td>May 19, 2018</td>
-			<td>November 2019</td>
+			<td>November 2019 (LTS)</td>
 			<td>Yuanhan Liu</td>
 		</tr>
+		<tr>
+			<td>18.02.1</td>
+			<td>April 6, 2018</td>
+			<td>June 2018</td>
+			<td>Luca Boccassi</td>
+		</tr>
+		<tr>
+			<td>18.05.1</td>
+			<td>June 29, 2018</td>
+			<td>October 2018</td>
+			<td>Christian Ehrhardt</td>
+		</tr>
+		<tr>
+			<td>18.08.1</td>
+			<td>October 5, 2018</td>
+			<td>January 2019</td>
+			<td>looking for volunteer</td>
+		</tr>
+		<tr>
+			<td>18.11.1</td>
+			<td>January 11, 2019</td>
+			<td>November 2020 (LTS)</td>
+			<td>Kevin Traynor</td>
+		</tr>
 	</table>
 	</div>
 </section>
-- 
2.16.2

Re: [dpdk-web] [PATCH v2] update stable releases roadmap

[Luca Boccassi]

On Wed, 2018-04-11 at 01:28 +0200, Thomas Monjalon wrote:
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> Patch for the website (to web@dpdk.org) Cc'ed to dev@dpdk.org
> 
> v2:
> 	- more volunteers
> 	- propose to do .1 release after -rc1 of next branch.

Acked-by: Luca Boccassi <bluca@debian.org>

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-web] [PATCH v2] update stable releases roadmap

[Christian Ehrhardt]

On Wed, Apr 11, 2018 at 1:28 AM, Thomas Monjalon <thomas@monjalon.net>
wrote:

> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> Patch for the website (to web@dpdk.org) Cc'ed to dev@dpdk.org
>
> v2:
>         - more volunteers
>         - propose to do .1 release after -rc1 of next branch.
>
> ---
>  dev/roadmap.html | 37 ++++++++++++++++++++++++++++++++-----
>  1 file changed, 32 insertions(+), 5 deletions(-)
>
> [...]
> +               <tr>
> +                       <td>18.05.1</td>
> +                       <td>June 29, 2018</td>
> +                       <td>October 2018</td>
> +                       <td>Christian Ehrhardt</td>
> +               </tr>
>

Acked-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

Re: [dpdk-web] [PATCH v2] update stable releases roadmap

[Kevin Traynor]

On 04/11/2018 12:28 AM, Thomas Monjalon wrote:
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> Patch for the website (to web@dpdk.org) Cc'ed to dev@dpdk.org
> 
> v2:
> 	- more volunteers
> 	- propose to do .1 release after -rc1 of next branch.
> 
> ---

Acked-by: Kevin Traynor <ktraynor@redhat.com>

Re: [dpdk-web] [PATCH v2] update stable releases roadmap

[Ferruh Yigit]

On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
> -	<p>Typically a new stable release version follows a mainline release
> -	by 1-2 weeks, depending on the test results.
> +	<p>The first stable release (.1) of a branch should follow
> +	its mainline release (.0) by at least two months,
> +	after the first release candidate (-rc1) of the next branch.

Hi Thomas,

What this change suggest? To be able to backport patches from rc1?

Re: [dpdk-web] [PATCH v2] update stable releases roadmap

[Thomas Monjalon]

18/04/2018 11:05, Ferruh Yigit:
> On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
> > -	<p>Typically a new stable release version follows a mainline release
> > -	by 1-2 weeks, depending on the test results.
> > +	<p>The first stable release (.1) of a branch should follow
> > +	its mainline release (.0) by at least two months,
> > +	after the first release candidate (-rc1) of the next branch.
> 
> Hi Thomas,
> 
> What this change suggest? To be able to backport patches from rc1?

Yes, it is the proposal we discussed earlier.
We can wait one week after RC1 to get some validation confirmation.
Do you agree?

Re: [dpdk-web] [PATCH v2] update stable releases roadmap

[Ferruh Yigit]

On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
> 18/04/2018 11:05, Ferruh Yigit:
>> On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
>>> -	<p>Typically a new stable release version follows a mainline release
>>> -	by 1-2 weeks, depending on the test results.
>>> +	<p>The first stable release (.1) of a branch should follow
>>> +	its mainline release (.0) by at least two months,
>>> +	after the first release candidate (-rc1) of the next branch.
>>
>> Hi Thomas,
>>
>> What this change suggest? To be able to backport patches from rc1?
> 
> Yes, it is the proposal we discussed earlier.
> We can wait one week after RC1 to get some validation confirmation.
> Do you agree?

This has been discussed in tech-board, what I remember the decision was to wait
the release to backport patches into stable tree.

Re: [dpdk-web] [PATCH v2] update stable releases roadmap

[Thomas Monjalon]

18/04/2018 14:28, Ferruh Yigit:
> On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
> > 18/04/2018 11:05, Ferruh Yigit:
> >> On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
> >>> -	<p>Typically a new stable release version follows a mainline release
> >>> -	by 1-2 weeks, depending on the test results.
> >>> +	<p>The first stable release (.1) of a branch should follow
> >>> +	its mainline release (.0) by at least two months,
> >>> +	after the first release candidate (-rc1) of the next branch.
> >>
> >> Hi Thomas,
> >>
> >> What this change suggest? To be able to backport patches from rc1?
> > 
> > Yes, it is the proposal we discussed earlier.
> > We can wait one week after RC1 to get some validation confirmation.
> > Do you agree?
> 
> This has been discussed in tech-board, what I remember the decision was to wait
> the release to backport patches into stable tree.

It was not so clear to me.
I thought post-rc1 was acceptable. The idea is to speed-up stable releases
pace, especially first release of a series.

Re: [dpdk-web] [PATCH v2] update stable releases roadmap

[Kevin Traynor]

On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
> 18/04/2018 14:28, Ferruh Yigit:
>> On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
>>> 18/04/2018 11:05, Ferruh Yigit:
>>>> On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
>>>>> -	<p>Typically a new stable release version follows a mainline release
>>>>> -	by 1-2 weeks, depending on the test results.
>>>>> +	<p>The first stable release (.1) of a branch should follow
>>>>> +	its mainline release (.0) by at least two months,
>>>>> +	after the first release candidate (-rc1) of the next branch.
>>>>
>>>> Hi Thomas,
>>>>
>>>> What this change suggest? To be able to backport patches from rc1?
>>>
>>> Yes, it is the proposal we discussed earlier.
>>> We can wait one week after RC1 to get some validation confirmation.
>>> Do you agree?
>>
>> This has been discussed in tech-board, what I remember the decision was to wait
>> the release to backport patches into stable tree.
> 

Any minutes? I couldn't find them

> It was not so clear to me.
> I thought post-rc1 was acceptable. The idea is to speed-up stable releases
> pace, especially first release of a series.
> 
> 

I think timing of stable releases and bugfix backports to the stable
branch are two separate items.

I do think that bugfix backports to stable should happen on a regular
basis (e.g. every 2 weeks). Otherwise we are back to the situation where
if there's a bugfix after a DPDK release, a user like (surprise,
surprise) OVS may not be able to use that DPDK version for ~3 months.

Someone who wants to get the latest bugfixes can just take the latest on
the stable branch and importantly, can have confidence that the
community has officially accepted those patches. If someone requires
stable to be validated, then they have to wait until the release.

Kevin.

Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap

[Aaron Conole]

Kevin Traynor <ktraynor@redhat.com> writes:

> On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
>> 18/04/2018 14:28, Ferruh Yigit:
>>> On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
>>>> 18/04/2018 11:05, Ferruh Yigit:
>>>>> On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
>>>>>> -	<p>Typically a new stable release version follows a mainline release
>>>>>> -	by 1-2 weeks, depending on the test results.
>>>>>> +	<p>The first stable release (.1) of a branch should follow
>>>>>> +	its mainline release (.0) by at least two months,
>>>>>> +	after the first release candidate (-rc1) of the next branch.
>>>>>
>>>>> Hi Thomas,
>>>>>
>>>>> What this change suggest? To be able to backport patches from rc1?
>>>>
>>>> Yes, it is the proposal we discussed earlier.
>>>> We can wait one week after RC1 to get some validation confirmation.
>>>> Do you agree?
>>>
>>> This has been discussed in tech-board, what I remember the decision was to wait
>>> the release to backport patches into stable tree.
>> 
>
> Any minutes? I couldn't find them
>
>> It was not so clear to me.
>> I thought post-rc1 was acceptable. The idea is to speed-up stable releases
>> pace, especially first release of a series.
>> 
>> 
>
> I think timing of stable releases and bugfix backports to the stable
> branch are two separate items.
>
> I do think that bugfix backports to stable should happen on a regular
> basis (e.g. every 2 weeks). Otherwise we are back to the situation where
> if there's a bugfix after a DPDK release, a user like (surprise,
> surprise) OVS may not be able to use that DPDK version for ~3 months.
>
> Someone who wants to get the latest bugfixes can just take the latest on
> the stable branch and importantly, can have confidence that the
> community has officially accepted those patches. If someone requires
> stable to be validated, then they have to wait until the release.

+1 - this seems to make the most sense to me.  Keep the patches flowing,
but don't label/tag it until validation.  That serves an additional
function: developers know their CC's to stable are being processed.

> Kevin.

Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap

[Ferruh Yigit]

On 4/20/2018 4:52 PM, Aaron Conole wrote:
> Kevin Traynor <ktraynor@redhat.com> writes:
> 
>> On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
>>> 18/04/2018 14:28, Ferruh Yigit:
>>>> On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
>>>>> 18/04/2018 11:05, Ferruh Yigit:
>>>>>> On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
>>>>>>> -	<p>Typically a new stable release version follows a mainline release
>>>>>>> -	by 1-2 weeks, depending on the test results.
>>>>>>> +	<p>The first stable release (.1) of a branch should follow
>>>>>>> +	its mainline release (.0) by at least two months,
>>>>>>> +	after the first release candidate (-rc1) of the next branch.
>>>>>>
>>>>>> Hi Thomas,
>>>>>>
>>>>>> What this change suggest? To be able to backport patches from rc1?
>>>>>
>>>>> Yes, it is the proposal we discussed earlier.
>>>>> We can wait one week after RC1 to get some validation confirmation.
>>>>> Do you agree?
>>>>
>>>> This has been discussed in tech-board, what I remember the decision was to wait
>>>> the release to backport patches into stable tree.
>>>
>>
>> Any minutes? I couldn't find them
>>
>>> It was not so clear to me.
>>> I thought post-rc1 was acceptable. The idea is to speed-up stable releases
>>> pace, especially first release of a series.
>>>
>>>
>>
>> I think timing of stable releases and bugfix backports to the stable
>> branch are two separate items.
>>
>> I do think that bugfix backports to stable should happen on a regular
>> basis (e.g. every 2 weeks). Otherwise we are back to the situation where
>> if there's a bugfix after a DPDK release, a user like (surprise,
>> surprise) OVS may not be able to use that DPDK version for ~3 months.
>>
>> Someone who wants to get the latest bugfixes can just take the latest on
>> the stable branch and importantly, can have confidence that the
>> community has officially accepted those patches. If someone requires
>> stable to be validated, then they have to wait until the release.
> 
> +1 - this seems to make the most sense to me.  Keep the patches flowing,
> but don't label/tag it until validation.  That serves an additional
> function: developers know their CC's to stable are being processed.

Are stable trees verified?

> 
>> Kevin.

Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap

[Luca Boccassi]

On Wed, 2018-04-25 at 09:33 +0100, Ferruh Yigit wrote:
> On 4/20/2018 4:52 PM, Aaron Conole wrote:
> > Kevin Traynor <ktraynor@redhat.com> writes:
> > 
> > > On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
> > > > 18/04/2018 14:28, Ferruh Yigit:
> > > > > On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
> > > > > > 18/04/2018 11:05, Ferruh Yigit:
> > > > > > > On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
> > > > > > > > -	<p>Typically a new stable release version
> > > > > > > > follows a mainline release
> > > > > > > > -	by 1-2 weeks, depending on the test results.
> > > > > > > > +	<p>The first stable release (.1) of a branch
> > > > > > > > should follow
> > > > > > > > +	its mainline release (.0) by at least two
> > > > > > > > months,
> > > > > > > > +	after the first release candidate (-rc1) of
> > > > > > > > the next branch.
> > > > > > > 
> > > > > > > Hi Thomas,
> > > > > > > 
> > > > > > > What this change suggest? To be able to backport patches
> > > > > > > from rc1?
> > > > > > 
> > > > > > Yes, it is the proposal we discussed earlier.
> > > > > > We can wait one week after RC1 to get some validation
> > > > > > confirmation.
> > > > > > Do you agree?
> > > > > 
> > > > > This has been discussed in tech-board, what I remember the
> > > > > decision was to wait
> > > > > the release to backport patches into stable tree.
> > > 
> > > Any minutes? I couldn't find them
> > > 
> > > > It was not so clear to me.
> > > > I thought post-rc1 was acceptable. The idea is to speed-up
> > > > stable releases
> > > > pace, especially first release of a series.
> > > > 
> > > > 
> > > 
> > > I think timing of stable releases and bugfix backports to the
> > > stable
> > > branch are two separate items.
> > > 
> > > I do think that bugfix backports to stable should happen on a
> > > regular
> > > basis (e.g. every 2 weeks). Otherwise we are back to the
> > > situation where
> > > if there's a bugfix after a DPDK release, a user like (surprise,
> > > surprise) OVS may not be able to use that DPDK version for ~3
> > > months.
> > > 
> > > Someone who wants to get the latest bugfixes can just take the
> > > latest on
> > > the stable branch and importantly, can have confidence that the
> > > community has officially accepted those patches. If someone
> > > requires
> > > stable to be validated, then they have to wait until the release.
> > 
> > +1 - this seems to make the most sense to me.  Keep the patches
> > flowing,
> > but don't label/tag it until validation.  That serves an additional
> > function: developers know their CC's to stable are being processed.
> 
> Are stable trees verified?

Verification is one issue - so far, Intel and ATT have provided time
and resources to do some regression tests, but only at release time
(before tagging). And it has been a manual process.
It would be great if more companies would step up to help - and even
better if regressions could be automated (nightly job?).

The other issue is deciding when a patch is "good to go" - until now,
the criteria has been "when it's merged into master".
So either that criteria needs to change, and another equally
"authoritative" is decided on, or patches should get reviewed and
merged in master more often and more quickly :-P

We also have not been looking directly at the the various -next trees,
as things are more "in-flux" there and could be reverted, or clash with
changes from other trees - hence why we merge from master.

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap

[Thomas Monjalon]

25/04/2018 12:03, Luca Boccassi:
> On Wed, 2018-04-25 at 09:33 +0100, Ferruh Yigit wrote:
> > On 4/20/2018 4:52 PM, Aaron Conole wrote:
> > > Kevin Traynor <ktraynor@redhat.com> writes:
> > > > On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
> > > > > 18/04/2018 14:28, Ferruh Yigit:
> > > > > > On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
> > > > > > > 18/04/2018 11:05, Ferruh Yigit:
> > > > > > > > On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
> > > > > > > > > -	<p>Typically a new stable release version
> > > > > > > > > follows a mainline release
> > > > > > > > > -	by 1-2 weeks, depending on the test results.
> > > > > > > > > +	<p>The first stable release (.1) of a branch
> > > > > > > > > should follow
> > > > > > > > > +	its mainline release (.0) by at least two
> > > > > > > > > months,
> > > > > > > > > +	after the first release candidate (-rc1) of
> > > > > > > > > the next branch.
> > > > > > > > 
> > > > > > > > Hi Thomas,
> > > > > > > > 
> > > > > > > > What this change suggest? To be able to backport patches
> > > > > > > > from rc1?
> > > > > > > 
> > > > > > > Yes, it is the proposal we discussed earlier.
> > > > > > > We can wait one week after RC1 to get some validation
> > > > > > > confirmation.
> > > > > > > Do you agree?
> > > > > > 
> > > > > > This has been discussed in tech-board, what I remember the
> > > > > > decision was to wait
> > > > > > the release to backport patches into stable tree.
> > > > 
> > > > Any minutes? I couldn't find them
> > > > 
> > > > > It was not so clear to me.
> > > > > I thought post-rc1 was acceptable. The idea is to speed-up
> > > > > stable releases
> > > > > pace, especially first release of a series.
> > > > > 
> > > > > 
> > > > 
> > > > I think timing of stable releases and bugfix backports to the
> > > > stable
> > > > branch are two separate items.
> > > > 
> > > > I do think that bugfix backports to stable should happen on a
> > > > regular
> > > > basis (e.g. every 2 weeks). Otherwise we are back to the
> > > > situation where
> > > > if there's a bugfix after a DPDK release, a user like (surprise,
> > > > surprise) OVS may not be able to use that DPDK version for ~3
> > > > months.
> > > > 
> > > > Someone who wants to get the latest bugfixes can just take the
> > > > latest on
> > > > the stable branch and importantly, can have confidence that the
> > > > community has officially accepted those patches. If someone
> > > > requires
> > > > stable to be validated, then they have to wait until the release.
> > > 
> > > +1 - this seems to make the most sense to me.  Keep the patches
> > > flowing,
> > > but don't label/tag it until validation.  That serves an additional
> > > function: developers know their CC's to stable are being processed.
> > 
> > Are stable trees verified?
> 
> Verification is one issue - so far, Intel and ATT have provided time
> and resources to do some regression tests, but only at release time
> (before tagging). And it has been a manual process.
> It would be great if more companies would step up to help - and even
> better if regressions could be automated (nightly job?).
> 
> The other issue is deciding when a patch is "good to go" - until now,
> the criteria has been "when it's merged into master".
> So either that criteria needs to change, and another equally
> "authoritative" is decided on, or patches should get reviewed and
> merged in master more often and more quickly :-P
> 
> We also have not been looking directly at the the various -next trees,
> as things are more "in-flux" there and could be reverted, or clash with
> changes from other trees - hence why we merge from master.

Yes, backporting from master is definitely the right thing to do.
Backporting more regularly would be also an improvement.
There will be always the question of the bug-free ideal in stable
branches. I agree we need more help to validate the stable branches.
But realistically, it will never be perfect.

So the questions are:
	- What we must wait before pushing a backport in the stable tree?
	- What we must wait before tagging a stable release?

I think it is reasonnable to push backports one or two weeks after
it is in the master branch, assuming master is tested by the community.
If a corner case is found later, it will be fixed with another patch.
That's why it's important to wait a validation period (happening after
each release candidate) before tagging a stable release.
So, if we are aware of a regression in the master branch, which has been
backported, we can wait few more days to fix it.
The last thing we need to consider before tagging, is the validation of
the stable release itself. Are we able to run some non-regression tests
on the stable branch if it is ready few days after a RC1?

Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap

[Aaron Conole]

Thomas Monjalon <thomas@monjalon.net> writes:

> 25/04/2018 12:03, Luca Boccassi:
>> On Wed, 2018-04-25 at 09:33 +0100, Ferruh Yigit wrote:
>> > On 4/20/2018 4:52 PM, Aaron Conole wrote:
>> > > Kevin Traynor <ktraynor@redhat.com> writes:
>> > > > On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
>> > > > > 18/04/2018 14:28, Ferruh Yigit:
>> > > > > > On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
>> > > > > > > 18/04/2018 11:05, Ferruh Yigit:
>> > > > > > > > On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
>> > > > > > > > > -	<p>Typically a new stable release version
>> > > > > > > > > follows a mainline release
>> > > > > > > > > -	by 1-2 weeks, depending on the test results.
>> > > > > > > > > +	<p>The first stable release (.1) of a branch
>> > > > > > > > > should follow
>> > > > > > > > > +	its mainline release (.0) by at least two
>> > > > > > > > > months,
>> > > > > > > > > +	after the first release candidate (-rc1) of
>> > > > > > > > > the next branch.
>> > > > > > > > 
>> > > > > > > > Hi Thomas,
>> > > > > > > > 
>> > > > > > > > What this change suggest? To be able to backport patches
>> > > > > > > > from rc1?
>> > > > > > > 
>> > > > > > > Yes, it is the proposal we discussed earlier.
>> > > > > > > We can wait one week after RC1 to get some validation
>> > > > > > > confirmation.
>> > > > > > > Do you agree?
>> > > > > > 
>> > > > > > This has been discussed in tech-board, what I remember the
>> > > > > > decision was to wait
>> > > > > > the release to backport patches into stable tree.
>> > > > 
>> > > > Any minutes? I couldn't find them
>> > > > 
>> > > > > It was not so clear to me.
>> > > > > I thought post-rc1 was acceptable. The idea is to speed-up
>> > > > > stable releases
>> > > > > pace, especially first release of a series.
>> > > > > 
>> > > > > 
>> > > > 
>> > > > I think timing of stable releases and bugfix backports to the
>> > > > stable
>> > > > branch are two separate items.
>> > > > 
>> > > > I do think that bugfix backports to stable should happen on a
>> > > > regular
>> > > > basis (e.g. every 2 weeks). Otherwise we are back to the
>> > > > situation where
>> > > > if there's a bugfix after a DPDK release, a user like (surprise,
>> > > > surprise) OVS may not be able to use that DPDK version for ~3
>> > > > months.
>> > > > 
>> > > > Someone who wants to get the latest bugfixes can just take the
>> > > > latest on
>> > > > the stable branch and importantly, can have confidence that the
>> > > > community has officially accepted those patches. If someone
>> > > > requires
>> > > > stable to be validated, then they have to wait until the release.
>> > > 
>> > > +1 - this seems to make the most sense to me.  Keep the patches
>> > > flowing,
>> > > but don't label/tag it until validation.  That serves an additional
>> > > function: developers know their CC's to stable are being processed.
>> > 
>> > Are stable trees verified?
>> 
>> Verification is one issue - so far, Intel and ATT have provided time
>> and resources to do some regression tests, but only at release time
>> (before tagging). And it has been a manual process.
>> It would be great if more companies would step up to help - and even
>> better if regressions could be automated (nightly job?).
>> 
>> The other issue is deciding when a patch is "good to go" - until now,
>> the criteria has been "when it's merged into master".
>> So either that criteria needs to change, and another equally
>> "authoritative" is decided on, or patches should get reviewed and
>> merged in master more often and more quickly :-P
>> 
>> We also have not been looking directly at the the various -next trees,
>> as things are more "in-flux" there and could be reverted, or clash with
>> changes from other trees - hence why we merge from master.
>
> Yes, backporting from master is definitely the right thing to do.
> Backporting more regularly would be also an improvement.
> There will be always the question of the bug-free ideal in stable
> branches. I agree we need more help to validate the stable branches.
> But realistically, it will never be perfect.
>
> So the questions are:
> 	- What we must wait before pushing a backport in the stable tree?
> 	- What we must wait before tagging a stable release?
>
> I think it is reasonnable to push backports one or two weeks after
> it is in the master branch, assuming master is tested by the community.
> If a corner case is found later, it will be fixed with another patch.

+1 - I agree here.  Folks who truly care about 'validated stable'
(whatever definition that takes) will only use a labeled version anyway.

OTOH, developers who want to see that their patches are landing in
stable (and more over, who want to ensure that their proposed backports
are actually complete - which is more relevant w.r.t. hardware),
shouldn't have to wait for the label.

Most other projects work this way, as well.  Keep pulling in the
relevant patches from master to the stable branch(es).  Do the official
label / release at a certain point in time relative to the main release
(or as needed in the case of "oh no, a serious bug here").

> That's why it's important to wait a validation period (happening after
> each release candidate) before tagging a stable release.
> So, if we are aware of a regression in the master branch, which has been
> backported, we can wait few more days to fix it.
> The last thing we need to consider before tagging, is the validation of
> the stable release itself. Are we able to run some non-regression tests
> on the stable branch if it is ready few days after a RC1?

Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap

[Kevin Traynor]

On 05/01/2018 03:16 PM, Aaron Conole wrote:
> Thomas Monjalon <thomas@monjalon.net> writes:
> 
>> 25/04/2018 12:03, Luca Boccassi:
>>> On Wed, 2018-04-25 at 09:33 +0100, Ferruh Yigit wrote:
>>>> On 4/20/2018 4:52 PM, Aaron Conole wrote:
>>>>> Kevin Traynor <ktraynor@redhat.com> writes:
>>>>>> On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
>>>>>>> 18/04/2018 14:28, Ferruh Yigit:
>>>>>>>> On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
>>>>>>>>> 18/04/2018 11:05, Ferruh Yigit:
>>>>>>>>>> On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
>>>>>>>>>>> -	<p>Typically a new stable release version
>>>>>>>>>>> follows a mainline release
>>>>>>>>>>> -	by 1-2 weeks, depending on the test results.
>>>>>>>>>>> +	<p>The first stable release (.1) of a branch
>>>>>>>>>>> should follow
>>>>>>>>>>> +	its mainline release (.0) by at least two
>>>>>>>>>>> months,
>>>>>>>>>>> +	after the first release candidate (-rc1) of
>>>>>>>>>>> the next branch.
>>>>>>>>>>
>>>>>>>>>> Hi Thomas,
>>>>>>>>>>
>>>>>>>>>> What this change suggest? To be able to backport patches
>>>>>>>>>> from rc1?
>>>>>>>>>
>>>>>>>>> Yes, it is the proposal we discussed earlier.
>>>>>>>>> We can wait one week after RC1 to get some validation
>>>>>>>>> confirmation.
>>>>>>>>> Do you agree?
>>>>>>>>
>>>>>>>> This has been discussed in tech-board, what I remember the
>>>>>>>> decision was to wait
>>>>>>>> the release to backport patches into stable tree.
>>>>>>
>>>>>> Any minutes? I couldn't find them
>>>>>>
>>>>>>> It was not so clear to me.
>>>>>>> I thought post-rc1 was acceptable. The idea is to speed-up
>>>>>>> stable releases
>>>>>>> pace, especially first release of a series.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I think timing of stable releases and bugfix backports to the
>>>>>> stable
>>>>>> branch are two separate items.
>>>>>>
>>>>>> I do think that bugfix backports to stable should happen on a
>>>>>> regular
>>>>>> basis (e.g. every 2 weeks). Otherwise we are back to the
>>>>>> situation where
>>>>>> if there's a bugfix after a DPDK release, a user like (surprise,
>>>>>> surprise) OVS may not be able to use that DPDK version for ~3
>>>>>> months.
>>>>>>
>>>>>> Someone who wants to get the latest bugfixes can just take the
>>>>>> latest on
>>>>>> the stable branch and importantly, can have confidence that the
>>>>>> community has officially accepted those patches. If someone
>>>>>> requires
>>>>>> stable to be validated, then they have to wait until the release.
>>>>>
>>>>> +1 - this seems to make the most sense to me.  Keep the patches
>>>>> flowing,
>>>>> but don't label/tag it until validation.  That serves an additional
>>>>> function: developers know their CC's to stable are being processed.
>>>>
>>>> Are stable trees verified?
>>>
>>> Verification is one issue - so far, Intel and ATT have provided time
>>> and resources to do some regression tests, but only at release time
>>> (before tagging). And it has been a manual process.
>>> It would be great if more companies would step up to help - and even
>>> better if regressions could be automated (nightly job?).
>>>
>>> The other issue is deciding when a patch is "good to go" - until now,
>>> the criteria has been "when it's merged into master".
>>> So either that criteria needs to change, and another equally
>>> "authoritative" is decided on, or patches should get reviewed and
>>> merged in master more often and more quickly :-P
>>>
>>> We also have not been looking directly at the the various -next trees,
>>> as things are more "in-flux" there and could be reverted, or clash with
>>> changes from other trees - hence why we merge from master.
>>
>> Yes, backporting from master is definitely the right thing to do.
>> Backporting more regularly would be also an improvement.
>> There will be always the question of the bug-free ideal in stable
>> branches. I agree we need more help to validate the stable branches.
>> But realistically, it will never be perfect.
>>
>> So the questions are:
>> 	- What we must wait before pushing a backport in the stable tree?
>> 	- What we must wait before tagging a stable release?
>>
>> I think it is reasonnable to push backports one or two weeks after
>> it is in the master branch, assuming master is tested by the community.
>> If a corner case is found later, it will be fixed with another patch.
> 
> +1 - I agree here.  Folks who truly care about 'validated stable'
> (whatever definition that takes) will only use a labeled version anyway.
> 
> OTOH, developers who want to see that their patches are landing in
> stable (and more over, who want to ensure that their proposed backports
> are actually complete - which is more relevant w.r.t. hardware),
> shouldn't have to wait for the label.
> 
> Most other projects work this way, as well.  Keep pulling in the
> relevant patches from master to the stable branch(es).  Do the official
> label / release at a certain point in time relative to the main release
> (or as needed in the case of "oh no, a serious bug here").
> 

I agree and I think it's the best way. However, it also requires
semi-frequent pull request merging into the master branch for this to
work. Otherwise there is still delay, just earlier in the process.

Not sure if there is a written/un-written workflow for when the next-*
branches merge into master at the moment?

>> That's why it's important to wait a validation period (happening after
>> each release candidate) before tagging a stable release.
>> So, if we are aware of a regression in the master branch, which has been
>> backported, we can wait few more days to fix it.
>> The last thing we need to consider before tagging, is the validation of
>> the stable release itself. Are we able to run some non-regression tests
>> on the stable branch if it is ready few days after a RC1?

Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap

[Thomas Monjalon]

01/05/2018 17:46, Kevin Traynor:
> On 05/01/2018 03:16 PM, Aaron Conole wrote:
> > Thomas Monjalon <thomas@monjalon.net> writes:
> >> So the questions are:
> >> 	- What we must wait before pushing a backport in the stable tree?
> >> 	- What we must wait before tagging a stable release?
> >>
> >> I think it is reasonnable to push backports one or two weeks after
> >> it is in the master branch, assuming master is tested by the community.
> >> If a corner case is found later, it will be fixed with another patch.
> > 
> > +1 - I agree here.  Folks who truly care about 'validated stable'
> > (whatever definition that takes) will only use a labeled version anyway.
> > 
> > OTOH, developers who want to see that their patches are landing in
> > stable (and more over, who want to ensure that their proposed backports
> > are actually complete - which is more relevant w.r.t. hardware),
> > shouldn't have to wait for the label.
> > 
> > Most other projects work this way, as well.  Keep pulling in the
> > relevant patches from master to the stable branch(es).  Do the official
> > label / release at a certain point in time relative to the main release
> > (or as needed in the case of "oh no, a serious bug here").
> > 
> 
> I agree and I think it's the best way. However, it also requires
> semi-frequent pull request merging into the master branch for this to
> work. Otherwise there is still delay, just earlier in the process.
> 
> Not sure if there is a written/un-written workflow for when the next-*
> branches merge into master at the moment?

We try to have more pulls before RC1.
It is not formal yet.

[dpdk-web] [PATCH v3] update stable releases roadmap

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
---
The proposed change of last versions (about shortening delays)
is dropped in this v3, as agreed during discussions in this list
and in the technical board.
---
 dev/roadmap.html | 40 +++++++++++++++++++++++++++++++++-------
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/dev/roadmap.html b/dev/roadmap.html
index f66c59a..aabdbf4 100644
--- a/dev/roadmap.html
+++ b/dev/roadmap.html
@@ -102,13 +102,15 @@
 		<li>Integration deadline: June 29, 2018
 		<li>Release: August 1, 2018
 	</ul>
-	<p>18.11
+	<p>18.11 (LTS)
 	<ul>
 		<li>Proposal deadline: September 7, 2018
 		<li>Integration deadline: October 5, 2018
 		<li>Release: November 2, 2018
 	</ul>
 	<h2 id="stable">Stable releases</h2>
+	<p>There is a documentation page describing the
+	<a href="/doc/guides/contributing/stable.html">guidelines of the stable releases</a>.
 	<p>Stable point releases follow mainline releases.
 	<p>After each -rc tag and after the final version, relevant bug fixes get
 	backported by the stable maintainers into the respective branches in "bursts".
@@ -128,17 +130,41 @@
 			<th>Maintainer</th>
 		</tr>
 		<tr>
-			<td>16.11.6</td>
-			<td>May 19, 2018</td>
-			<td>November 2018</td>
+			<td>16.11.7</td>
+			<td>June 8, 2018</td>
+			<td>November 2018 (LTS)</td>
 			<td>Luca Boccassi</td>
 		</tr>
 		<tr>
-			<td>17.11.2</td>
-			<td>May 19, 2018</td>
-			<td>November 2019</td>
+			<td>17.11.3</td>
+			<td>June 8, 2018</td>
+			<td>November 2019 (LTS)</td>
 			<td>Yuanhan Liu</td>
 		</tr>
+		<tr>
+			<td>18.02.2</td>
+			<td>June 8, 2018</td>
+			<td>June 2018</td>
+			<td>Luca Boccassi</td>
+		</tr>
+		<tr>
+			<td>18.05.1</td>
+			<td>August 24, 2018</td>
+			<td>August 2018</td>
+			<td>Christian Ehrhardt</td>
+		</tr>
+		<tr>
+			<td>18.08.1</td>
+			<td>November 16, 2018</td>
+			<td>November 2018</td>
+			<td>looking for volunteer</td>
+		</tr>
+		<tr>
+			<td>18.11.1</td>
+			<td>January 11, 2019</td>
+			<td>November 2020 (LTS)</td>
+			<td>Kevin Traynor</td>
+		</tr>
 	</table>
 	</div>
 </section>
-- 
2.16.2

Re: [dpdk-web] [PATCH v3] update stable releases roadmap

[Ferruh Yigit]

On 5/17/2018 5:32 PM, Thomas Monjalon wrote:
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Acked-by: Luca Boccassi <bluca@debian.org>
> Acked-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> Acked-by: Kevin Traynor <ktraynor@redhat.com>

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Re: [dpdk-web] [PATCH v3] update stable releases roadmap

[Thomas Monjalon]

17/05/2018 18:41, Ferruh Yigit:
> On 5/17/2018 5:32 PM, Thomas Monjalon wrote:
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > Acked-by: Luca Boccassi <bluca@debian.org>
> > Acked-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> > Acked-by: Kevin Traynor <ktraynor@redhat.com>
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied: http://dpdk.org/dev/roadmap#stable