On Fri, Jun 03, 2016 at 06:05:15PM +0200, Thomas Monjalon wrote:
> 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.
>
> > The purpose of the DPDK LTS will be to maintain a stable release of DPDK
> > with
> > backported bug 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 proposed maintainer for the LTS is Yuanhan Liu
> > <yuanhan.liu at linux.intel.com>.
>
> I wonder if Yuanhan is OK to maintain every stable releases which could be
> requested/needed?
I'm Okay, since I assume the maintain effort would be small: mainly
for picking acked and tested *bug fix* patches.
> 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 have no object though, if somebody volunteer him as a stable branch
maintainer.
>
> > 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?
>
> > 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?
>
> > What changes should be backported
> > ---------------------------------
> >
> > * Bug fixes that don't break the ABI.
>
> And API?
> And behaviour (if not clearly documented in the API)?
Agreed, we should not include those changes, either.
>
> [...]
> > Developers submitting fixes to the mainline should also CC the maintainer so
> > that they can evaluate the patch. A <stable at dpdk.org> email address
> > could be
> > provided for this so that it can be included as a CC in the commit messages
> > and documented in the Code Contribution Guidelines.
>
> Why?
> We must avoid putting too much restrictions on the contributors.
This is actually requested by me, in a behaviour similar to Linux
kernel community takes. Here is the thing, the developer normally
knows better than a generic maintainer (assume it's me) that a patch
applies to stable branch or not. This is especially true for DPDK,
since we ask the developer to note down the bug commit by adding a
fix line.
It wouldn't be a burden for an active contributor, as CCing to related
people (including right mailing list) is a good habit they already
have. For some one-time contributors, it's okay that they don't know
and follow it.
In such case, I guess we need the help from the related subsystem
maintainer: if it's a good bug fix that applies to stable branch,
and the contributor forgot to make a explicit cc to stable mailing
list, the subsystem maintainer should forward or ask him to forward
to stable mailing list.
The reason I'm asking is that as a generic maintainer, there is
simply no such energy to keep an eye on all patches: you have to
be aware of that we have thoughts of email per month from dpdk dev
mailing list: the number of last month is 1808.
Doing so would allow one person maintain several stable tree
be possible.
For more info, you could check linux/Documentation/stable_kernel_rules.txt.
>
> > Intel will provide validation engineers to test the LTS branch/tree. Tested
> > releases can be marked using a Git tag with an incremented revision number.
> > For
> > example: 16.07.00_LTS -> 16.07.01_LTS. The testing cadence should be
> > quarterly
> > but will be best effort only and dependent on available resources.
>
> Thanks
> It must not be just a tag. There should be an announce and a tarball ready
> to download.
Agreed.
--yliu
