From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f196.google.com (mail-wr0-f196.google.com [209.85.128.196]) by dpdk.org (Postfix) with ESMTP id C85676CA2; Fri, 9 Mar 2018 18:30:29 +0100 (CET) Received: by mail-wr0-f196.google.com with SMTP id f14so9741541wre.8; Fri, 09 Mar 2018 09:30:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=jNHPQjQ5GsD9VJydl+QO+ogQ6GIB87AnIwrDJrvtJ1w=; b=rPkHu1ksLTGjzqt62fR0H9doKua6J2CTHYW6pmicgQLXuI+K0viS3eNWNtK6TiS3h1 wRgKns6h2LhJUGR1wjUFClqDXctIPWzMEG/cJD3489I4Gh//VFmSbuIYkN1KPiPH+psu N9sGitIYGHuvS63jJVG6uvgD/9QRHgQ8CI/Goen4N1+Ckk/vhhMhx1SDxHUJLOlKAUoN gvW1eiz7bBlq+/9U6yhveACAHKeE8Yb3S7wjhdBv2ESfdV7QdV7nq3XEb1d9y9XO14en Efdy8OTjKcRQYxSfeTw6RAJfJwMJOC7DhmjADLrMIO6H1aKojQfcsv0U0+P/lgbiLCqd hdIw== X-Gm-Message-State: APf1xPBtNC/25ytcvcSZXdBUPJBR0feqa713A+Rp36QCoPgo/4Ft0h2u OF8yXgnjwDXKZd7wPu5/It8= X-Google-Smtp-Source: AG47ELsOHWWX8znnkPkdtQpNk0WGZcO9u52LoZbsxA01ZE6FPeb/hIRR9XmbX7d0cZnGTt6U8En62Q== X-Received: by 10.223.178.232 with SMTP id g95mr28441996wrd.35.1520616628952; Fri, 09 Mar 2018 09:30:28 -0800 (PST) Received: from localhost ([2a00:23c5:be85:1400:6930:196b:56ac:33db]) by smtp.gmail.com with ESMTPSA id e10sm1599664wrh.38.2018.03.09.09.30.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Mar 2018 09:30:28 -0800 (PST) Message-ID: <1520616627.5685.10.camel@debian.org> From: Luca Boccassi To: Thomas Monjalon , Ferruh Yigit Cc: "Ananyev, Konstantin" , "web@dpdk.org" , "yliu@fridaylinux.org" , "ktraynor@redhat.com" , "techboard@dpdk.org" Date: Fri, 09 Mar 2018 17:30:27 +0000 In-Reply-To: <1763732.gKnBn278kB@xps> References: <20180309133612.19927-1-thomas@monjalon.net> <138268661.yuZPGn2xFY@xps> <1763732.gKnBn278kB@xps> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Subject: Re: [dpdk-web] [dpdk-techboard] [PATCH] update stable releases roadmap X-BeenThere: web@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK website maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 17:30:30 -0000 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 > > > > > > >=20 > > > > > > > --- > > > > > > > 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. > > > > > > >=20 > > > > > > > Let's add this discussion to the agenda of the next > > > > > > > techboard > > > > > > > meeting. > > > > > >=20 > > > > > > The issue is how to decide what goes into a stable release, > > > > > > if it does > > > > > > not follow a main release. > > > > > >=20 > > > > > > 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? > > > > >=20 > > > > > If we pull patches more regularly in master, there can be a > > > > > lot of fixes > > > > > accumulated during 2 months. > > > >=20 > > > > But these patches need to be properly tested before going into > > > > LTS, right? > > > > So it means extra effort for the validation teams? > > >=20 > > > 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. > >=20 > > I have same concern with Konstantin. > >=20 > > Why merging unverified patches to the stable tree? It is not > > uncommon that we > > fix fixes during rc phase. > >=20 > > I am for waiting proper release to backport fixes to the stable > > release. >=20 > It is a valid concern. >=20 > > 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. > >=20 > > Is there a request received to get stable trees earlier? What is > > the motivation > > of the change? >=20 > 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. >=20 > 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. >=20 > 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. --=20 Kind regards, Luca Boccassi