DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] DPDK short term stable maintenance
@ 2019-03-12 19:12 Kevin Traynor
  2019-03-12 20:46 ` Luca Boccassi
  0 siblings, 1 reply; 6+ messages in thread
From: Kevin Traynor @ 2019-03-12 19:12 UTC (permalink / raw)
  To: dev
  Cc: Luca Boccassi, Yongseok Koh, Thomas Monjalon, Ferruh Yigit,
	John McNamara, Aaron Conole, Walker, Benjamin, Jay Rolette

Hi All,

This is about short term stable maintenance, ~3 months based on
n.02/05/08 DPDK. It is **not** referring/impacting DPDK LTS, maintained
for ~2 years based on n.11 DPDK.

The effort and usefulness of short term stable maintenance was raised
previously and in the last DPDK Release meeting [1], so sending mail to
kick off discussion here...

Currently DPDK 19.02 stable branch has no maintainer and it has been
difficult to get the companies to validate DPDK 18.08.1 RC. There seems
to be a lack of appetite in the community for short term stables, or at
least for all of them, and hence giving resources for helping them.

It could be that users are either moving from latest bleeding edge
master release to the next, or settling on DPDK LTS for an extended
period of time - I'm just speculating, but IMHO that would not be a bad
thing.

So what to do with short term stables? Some choices could be:

- continue with short term stables for n.02/05/08
- ad-hoc support for short term stables where community have an interest
in a particular one
- have a maintainer to backport fixes on a public branch, but have no
releases, or have unvalidated/best effort validated releases
- no short term stable branches/releases

Probably there's other ideas too. Obviously most of the above would need
resources from the community to proceed. One advantage of not having
short term stables is that there might be more resources available for
maintenance/validation of master and LTS DPDK releases.

Thoughts?

thanks,
Kevin.

[1] https://mails.dpdk.org/archives/dev/2019-March/126006.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] DPDK short term stable maintenance
  2019-03-12 19:12 [dpdk-dev] DPDK short term stable maintenance Kevin Traynor
@ 2019-03-12 20:46 ` Luca Boccassi
  2019-03-12 20:51   ` Thomas Monjalon
  2019-03-22 10:45   ` Kevin Traynor
  0 siblings, 2 replies; 6+ messages in thread
From: Luca Boccassi @ 2019-03-12 20:46 UTC (permalink / raw)
  To: Kevin Traynor, dev
  Cc: Yongseok Koh, Thomas Monjalon, Ferruh Yigit, John McNamara,
	Aaron Conole, Walker, Benjamin, Jay Rolette

On Tue, 2019-03-12 at 19:12 +0000, Kevin Traynor wrote:
> Hi All,
> 
> This is about short term stable maintenance, ~3 months based on
> n.02/05/08 DPDK. It is **not** referring/impacting DPDK LTS,
> maintained
> for ~2 years based on n.11 DPDK.
> 
> The effort and usefulness of short term stable maintenance was raised
> previously and in the last DPDK Release meeting [1], so sending mail
> to
> kick off discussion here...
> 
> Currently DPDK 19.02 stable branch has no maintainer and it has been
> difficult to get the companies to validate DPDK 18.08.1 RC. There
> seems
> to be a lack of appetite in the community for short term stables, or
> at
> least for all of them, and hence giving resources for helping them.
> 
> It could be that users are either moving from latest bleeding edge
> master release to the next, or settling on DPDK LTS for an extended
> period of time - I'm just speculating, but IMHO that would not be a
> bad
> thing.
> 
> So what to do with short term stables? Some choices could be:
> 
> - continue with short term stables for n.02/05/08
> - ad-hoc support for short term stables where community have an
> interest
> in a particular one
> - have a maintainer to backport fixes on a public branch, but have no
> releases, or have unvalidated/best effort validated releases
> - no short term stable branches/releases
> 
> Probably there's other ideas too. Obviously most of the above would
> need
> resources from the community to proceed. One advantage of not having
> short term stables is that there might be more resources available
> for
> maintenance/validation of master and LTS DPDK releases.
> 
> Thoughts?
> 
> thanks,
> Kevin.
> 
> [1] https://mails.dpdk.org/archives/dev/2019-March/126006.html

Hi,

Thanks for starting the discussion.

My 2c is that, unless someone steps up not only for the maintainer role
but also for the validation effort, we should cancel the short term
releases.

-- 
Kind regards,
Luca Boccassi

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] DPDK short term stable maintenance
  2019-03-12 20:46 ` Luca Boccassi
@ 2019-03-12 20:51   ` Thomas Monjalon
  2019-03-12 23:49     ` Stephen Hemminger
  2019-03-22 10:45   ` Kevin Traynor
  1 sibling, 1 reply; 6+ messages in thread
From: Thomas Monjalon @ 2019-03-12 20:51 UTC (permalink / raw)
  To: Luca Boccassi, Kevin Traynor
  Cc: dev, Yongseok Koh, Ferruh Yigit, John McNamara, Aaron Conole,
	Walker, Benjamin, Jay Rolette

12/03/2019 21:46, Luca Boccassi:
> On Tue, 2019-03-12 at 19:12 +0000, Kevin Traynor wrote:
> > So what to do with short term stables? Some choices could be:
> > 
> > - continue with short term stables for n.02/05/08
> > - ad-hoc support for short term stables where community have an
> > interest
> > in a particular one
> > - have a maintainer to backport fixes on a public branch, but have no
> > releases, or have unvalidated/best effort validated releases
> > - no short term stable branches/releases
> > 
> > Probably there's other ideas too. Obviously most of the above would
> > need
> > resources from the community to proceed. One advantage of not having
> > short term stables is that there might be more resources available
> > for
> > maintenance/validation of master and LTS DPDK releases.
[...]
> 
> My 2c is that, unless someone steps up not only for the maintainer role
> but also for the validation effort, we should cancel the short term
> releases.

Yes it looks reasonnable.
So we must question the community at each major release
to know if it will maintained, how long, or not.
If there are volunteers, we must clearly state in the stable release notes
which areas are validated.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] DPDK short term stable maintenance
  2019-03-12 20:51   ` Thomas Monjalon
@ 2019-03-12 23:49     ` Stephen Hemminger
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Hemminger @ 2019-03-12 23:49 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Luca Boccassi, Kevin Traynor, dev, Yongseok Koh, Ferruh Yigit,
	John McNamara, Aaron Conole, Walker, Benjamin, Jay Rolette

On Tue, 12 Mar 2019 21:51:37 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 12/03/2019 21:46, Luca Boccassi:
> > On Tue, 2019-03-12 at 19:12 +0000, Kevin Traynor wrote:  
> > > So what to do with short term stables? Some choices could be:
> > > 
> > > - continue with short term stables for n.02/05/08
> > > - ad-hoc support for short term stables where community have an
> > > interest
> > > in a particular one
> > > - have a maintainer to backport fixes on a public branch, but have no
> > > releases, or have unvalidated/best effort validated releases
> > > - no short term stable branches/releases
> > > 
> > > Probably there's other ideas too. Obviously most of the above would
> > > need
> > > resources from the community to proceed. One advantage of not having
> > > short term stables is that there might be more resources available
> > > for
> > > maintenance/validation of master and LTS DPDK releases.  
> [...]
> > 
> > My 2c is that, unless someone steps up not only for the maintainer role
> > but also for the validation effort, we should cancel the short term
> > releases.  
> 
> Yes it looks reasonnable.
> So we must question the community at each major release
> to know if it will maintained, how long, or not.
> If there are volunteers, we must clearly state in the stable release notes
> which areas are validated.

The validation is the major hurdle.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] DPDK short term stable maintenance
  2019-03-12 20:46 ` Luca Boccassi
  2019-03-12 20:51   ` Thomas Monjalon
@ 2019-03-22 10:45   ` Kevin Traynor
  2019-03-22 10:45     ` Kevin Traynor
  1 sibling, 1 reply; 6+ messages in thread
From: Kevin Traynor @ 2019-03-22 10:45 UTC (permalink / raw)
  To: Luca Boccassi, dev
  Cc: Yongseok Koh, Thomas Monjalon, Ferruh Yigit, John McNamara,
	Aaron Conole, Walker, Benjamin, Jay Rolette

On 12/03/2019 20:46, Luca Boccassi wrote:
> On Tue, 2019-03-12 at 19:12 +0000, Kevin Traynor wrote:
>> Hi All,
>>
>> This is about short term stable maintenance, ~3 months based on
>> n.02/05/08 DPDK. It is **not** referring/impacting DPDK LTS,
>> maintained
>> for ~2 years based on n.11 DPDK.
>>
>> The effort and usefulness of short term stable maintenance was raised
>> previously and in the last DPDK Release meeting [1], so sending mail
>> to
>> kick off discussion here...
>>
>> Currently DPDK 19.02 stable branch has no maintainer and it has been
>> difficult to get the companies to validate DPDK 18.08.1 RC. There
>> seems
>> to be a lack of appetite in the community for short term stables, or
>> at
>> least for all of them, and hence giving resources for helping them.
>>
>> It could be that users are either moving from latest bleeding edge
>> master release to the next, or settling on DPDK LTS for an extended
>> period of time - I'm just speculating, but IMHO that would not be a
>> bad
>> thing.
>>
>> So what to do with short term stables? Some choices could be:
>>
>> - continue with short term stables for n.02/05/08
>> - ad-hoc support for short term stables where community have an
>> interest
>> in a particular one
>> - have a maintainer to backport fixes on a public branch, but have no
>> releases, or have unvalidated/best effort validated releases
>> - no short term stable branches/releases
>>
>> Probably there's other ideas too. Obviously most of the above would
>> need
>> resources from the community to proceed. One advantage of not having
>> short term stables is that there might be more resources available
>> for
>> maintenance/validation of master and LTS DPDK releases.
>>
>> Thoughts?
>>
>> thanks,
>> Kevin.
>>
>> [1] https://mails.dpdk.org/archives/dev/2019-March/126006.html
> 
> Hi,
> 
> Thanks for starting the discussion.
> 
> My 2c is that, unless someone steps up not only for the maintainer role
> but also for the validation effort, we should cancel the short term
> releases.
> 

+1

In fact the docs do not make any commitment that there will be stables
(other than the LTSs), but in practice it has been the case that every
recent DPDK release has had a stable branch and stable release. I will
add a note in the docs that validation commitments are also needed for a
stable to proceed.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] DPDK short term stable maintenance
  2019-03-22 10:45   ` Kevin Traynor
@ 2019-03-22 10:45     ` Kevin Traynor
  0 siblings, 0 replies; 6+ messages in thread
From: Kevin Traynor @ 2019-03-22 10:45 UTC (permalink / raw)
  To: Luca Boccassi, dev
  Cc: Yongseok Koh, Thomas Monjalon, Ferruh Yigit, John McNamara,
	Aaron Conole, Walker, Benjamin, Jay Rolette

On 12/03/2019 20:46, Luca Boccassi wrote:
> On Tue, 2019-03-12 at 19:12 +0000, Kevin Traynor wrote:
>> Hi All,
>>
>> This is about short term stable maintenance, ~3 months based on
>> n.02/05/08 DPDK. It is **not** referring/impacting DPDK LTS,
>> maintained
>> for ~2 years based on n.11 DPDK.
>>
>> The effort and usefulness of short term stable maintenance was raised
>> previously and in the last DPDK Release meeting [1], so sending mail
>> to
>> kick off discussion here...
>>
>> Currently DPDK 19.02 stable branch has no maintainer and it has been
>> difficult to get the companies to validate DPDK 18.08.1 RC. There
>> seems
>> to be a lack of appetite in the community for short term stables, or
>> at
>> least for all of them, and hence giving resources for helping them.
>>
>> It could be that users are either moving from latest bleeding edge
>> master release to the next, or settling on DPDK LTS for an extended
>> period of time - I'm just speculating, but IMHO that would not be a
>> bad
>> thing.
>>
>> So what to do with short term stables? Some choices could be:
>>
>> - continue with short term stables for n.02/05/08
>> - ad-hoc support for short term stables where community have an
>> interest
>> in a particular one
>> - have a maintainer to backport fixes on a public branch, but have no
>> releases, or have unvalidated/best effort validated releases
>> - no short term stable branches/releases
>>
>> Probably there's other ideas too. Obviously most of the above would
>> need
>> resources from the community to proceed. One advantage of not having
>> short term stables is that there might be more resources available
>> for
>> maintenance/validation of master and LTS DPDK releases.
>>
>> Thoughts?
>>
>> thanks,
>> Kevin.
>>
>> [1] https://mails.dpdk.org/archives/dev/2019-March/126006.html
> 
> Hi,
> 
> Thanks for starting the discussion.
> 
> My 2c is that, unless someone steps up not only for the maintainer role
> but also for the validation effort, we should cancel the short term
> releases.
> 

+1

In fact the docs do not make any commitment that there will be stables
(other than the LTSs), but in practice it has been the case that every
recent DPDK release has had a stable branch and stable release. I will
add a note in the docs that validation commitments are also needed for a
stable to proceed.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-03-22 10:45 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-12 19:12 [dpdk-dev] DPDK short term stable maintenance Kevin Traynor
2019-03-12 20:46 ` Luca Boccassi
2019-03-12 20:51   ` Thomas Monjalon
2019-03-12 23:49     ` Stephen Hemminger
2019-03-22 10:45   ` Kevin Traynor
2019-03-22 10:45     ` Kevin Traynor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).