From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id C271B4D27; Fri, 9 Mar 2018 16:45:36 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4F54520D45; Fri, 9 Mar 2018 10:45:36 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 09 Mar 2018 10:45:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=J3uI8g6nnSnw5YXacOpD80EMVr g6b57nyLQTik01fKY=; b=nycpddqMPPDhI+yYtv/i2cuzEQtACKMofbQ4z5EJD+ Vu+RutDwStrYMEK5hsgtzgiNW5XjQz/bqdD0Yucs90sfEaQdP+vA2gmtIrrhHFvn jIaUgktgXbdYfGKcjNRtgCMVmmi56pgAtz1ZuY4mlfXfdKDBD3NP6bkqRjYE6+nj Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=J3uI8g 6nnSnw5YXacOpD80EMVrg6b57nyLQTik01fKY=; b=Quc42mxcBOsQ8i1mTuvnqT 0HwCxq626Niz2L0JcL4ssmhy1CZBL6O7C2GVvOBvgw6p+Xd9F2I7RuVE1mNeuLeT a63d/hXXFxpkNfl6aQR/k0gTsyyJRGXNc3C5nxAawpaynYj6d1CSt0YqgR2ABvAB /WkWjkZJSPWe1anhGvlg/QL0Jp5tD7nSCFBRqSzmp0+WUfOQSp83EbgECi/MkGy8 wP9OWZ7QUtaoxvoGtyJTvI9lvT1rbzGhg8XtbmpTpPr8AFInWroDkiy9lnElX1qe MNCjdKBTnPyLSxqGb4+USPVxCL8ix18Z652HD1oXpMJnwDBF9qJj8OXZHuNchWSw == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B75B24651; Fri, 9 Mar 2018 10:45:35 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit Cc: "Ananyev, Konstantin" , Luca Boccassi , "web@dpdk.org" , "yliu@fridaylinux.org" , "ktraynor@redhat.com" , "techboard@dpdk.org" Date: Fri, 09 Mar 2018 16:45:18 +0100 Message-ID: <1763732.gKnBn278kB@xps> In-Reply-To: References: <20180309133612.19927-1-thomas@monjalon.net> <138268661.yuZPGn2xFY@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 15:45:37 -0000 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 > >>>>> > >>>>> --- > >>>>> 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.