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

[Luca Boccassi <bluca@debian.org>]

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