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

[Thomas Monjalon <thomas@monjalon.net>]

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.