Re: [dpdk-dev] RFC: DPDK Long Term Support

["Mcnamara, John" <john.mcnamara@intel.com>]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, June 3, 2016 5:05 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org; Christian Ehrhardt <christian.ehrhardt@canonical.com>;
> Markos Chandras <mchandras@suse.de>; Panu Matilainen <pmatilai@redhat.com>
> Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support
> 
> Hi,
> 
> 2016-06-03 15:07, Mcnamara, John:
> > Introduction
> > ------------
> >
> > This document sets out a proposal for a DPDK Long Term Support release
> (LTS).
> 
> In general, LTS refer to a longer maintenance than than regular one.
> Here we are talking to doing some maintenance as stable releases first.
> Currently we have no maintenance at all.
> So I suggest to differentiate "stable branches" and "LTS" for some stable
> branches.

Hi Thomas,

I have no argument against this. It would be great to have a series of stable
branches of which some are LTS.

But at a minimum we are committing to have a least one maintained stable branch 
that will also be a LTS.

 
> I wonder if Yuanhan is OK to maintain every stable releases which could be
> requested/needed? Or should we have other committers for the stable
> releases that Yuanhan would not want to maintain himself?
> The Linux model is to let people declare themselves when they want to
> maintain a stable branch.


I think it is fine to have other committers.


> > The proposed duration of the LTS support is 2 years.
> 
> I think we should discuss the support duration for each release
> separately.
> 
> > There will only be one LTS branch being maintained at any time. At the
> > end of the 2 year cycle the maintenance on the previous LTS will be
> wound down.
> 
> Seems a bit too restrictive.
> Currently, there is no maintenance at all because nobody was volunteer.
> If Yuanhan is volunteer for a stable branch every 2 years, fine.
> If someone else is volunteer for other branches, why not let him do it?

I see no problem with that. This proposal just reflects that fact that we
have only had one volunteer to date and is based on what could be reasonably
done by one person (plus the validation support). If more maintainers come 
forward we can have more/more frequent stable branches.

We will, however, be constrained by the validation effort that can be offered, 
unless there are other validation volunteers.


> > The proposed initial LTS version will be DPDK 16.07. The next
> > versions, based on a 2 year cycle, will be DPDK 18.08, 20.08, etc.
> 
> Let's do a first run with 16.07 and see later what we want to do next.
> How long time a stable branch must be announced before its initial
> release?

Ok. The statement at the end about reviewing at the end of the first year
is meant to cover adjustments like this. I think that we will have to see
how things work out in practice and adjust as we go.



> > What changes should be backported
> > ---------------------------------
> >
> > * Bug fixes that don't break the ABI.
> 
> And API?
> And behaviour (if not clearly documented in the API)?


Yes. It should say ABI and API. Undocumented but implied or existing
bahaviour should also be maintained.


> > (OSV reps please confirm.)
> >
> > * Ubuntu 16.04 LTS
> > * RHEL 7.3
> > * SuSE 11 SP4 or 12
> > * FreeBSD 10.3
> 
> I'm sure there will be more validation on the field or from contributors.

Hopefully. :-)

John.
--