From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 94C7F2B8E for ; Thu, 16 Feb 2017 09:21:37 +0100 (CET) Received: by mail-wm0-f50.google.com with SMTP id v77so9063275wmv.0 for ; Thu, 16 Feb 2017 00:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=lkQ/hpx2kwsHr+O+kgckbMgPY3eZc8V51nbOzwf9KMM=; b=XXZDsWk83q6s5hXIG3b2WqecpnPI2CI929aEtICxtFDTOMMSP+9UceHCCYL4bsHJam wm02uUr3m1+bUKQDI6ubV9Uv3XpsOsWT3OdaLJ6o1CE63JFG0NE9MgMa1L8JZb9dqtx4 1geNZ0vG1FOFDxd23lvOCmvNgZwWt3vSjdhtXdYOkkEYQZMKMn14nJvKBmzHqSnWrXZu 9PfBwQypzyzum0vg6hCkiYajiqvbzrTPQlt3+lxtjK35ZfecRRkuiHmX3VMFaM8IhGD9 +1rhBHjj9RYsAShsSnw8pPwvtYwYkZykaSTA7iifMAsK6UfnkFHS/hn6LuSS1FHdP337 SybQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=lkQ/hpx2kwsHr+O+kgckbMgPY3eZc8V51nbOzwf9KMM=; b=heUAWhmovpsEP77Kva7t97fT0mpm5YY4rzLvNLiY6sfmdt05PyXk4wxU2yzTseVVOo dtaZaRs2F/xSCsGO2OxsY+D4LWhxfohwMinUCEsVNj8HQ70Y52U7NxPLA+pCGiTp0U9B 8RraPOjiRE1aCJJd0pG+SymBpYkHDm5PtL2uFgcbZ3b5XPKFXP6t00Q/DQYJeibegpEX 7yZ/PJN0SqRDUdeEMFovyqEQ7/MVEDWhrjp3jWrpfKk6nsVrGeXl777vgYPGH9ZhhG0E aV0QnffkzvPRhjoSyzqtkfaydKxriNPuzve4xnKosTKBRezxzKi8nWCiLFRxG44NPheb PRzA== X-Gm-Message-State: AMke39lHltDPBbxa+uq+/vvur/8v4su+OgKoXyHoo3GGRDT2S6jz4E/W5tBluMZ5xGj1p8zu X-Received: by 10.28.93.138 with SMTP id r132mr11425747wmb.17.1487233297239; Thu, 16 Feb 2017 00:21:37 -0800 (PST) Received: from autoinstall.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id h3sm7999321wrb.31.2017.02.16.00.21.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 00:21:36 -0800 (PST) Date: Thu, 16 Feb 2017 09:21:28 +0100 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Yuanhan Liu Cc: stable@dpdk.org, Thomas Monjalon Message-ID: <20170216082128.GA23344@autoinstall.dev.6wind.com> References: <20170215102345.GU23344@autoinstall.dev.6wind.com> <20170216050303.GA20916@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170216050303.GA20916@yliu-dev.sh.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-stable] What kind of commits can be backported to help the process X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 08:21:37 -0000 On Thu, Feb 16, 2017 at 01:03:03PM +0800, Yuanhan Liu wrote: > On Wed, Feb 15, 2017 at 11:23:45AM +0100, Nélio Laranjeiro wrote: > > Hi stable mailing list, > > > > As written in the subject, it is not fully clear on what kind of patches > > can enter this branch. > > > > Some fixes apply easily on top of other ones which may not be related, > > the question is on those "unrelated" patches. Is it acceptable to > > backport them, and if yes at what point is it acceptable depending on > > the nature of the patch: > > > > 1. Re-work: just a refactor of some structure, clean-up, ... > > 2. Behavior: it change the behavior of a part of the code, ... > > 3. Performances: it impacts performances (positively or negatively). > > 4. None, the patch must apply by itself. > > 5. ... > > > > What is the expectation for this branch? > > Here is the typical flow I took to pick commits to a specific stable > branch: > > - firstly, I will get a list of bug fixing commits, with the help of > devtools/git-log-fixes.sh (as well as the "cc: stable@dpdk.org" tag > inside the commit log). > > Those commits fix some bugs in a former releases, thus they will be > applied to a specific stable branch. > > - Some of them could be applied cleanly. I will then drop a note to > all related people (the author, the reviewer, etc) and stable list, > to inform that this commit will be in a specific stable release. > > - And some of them could not be applied cleanly, when conflicts happens > (code base could be changed). > > When that happens, I will try to backport it by myself if the commit > is simple enough (say, just few lines of code and the conflicts could > be easily fixed). > > If not, I will stop (to not mess something up because I'm not familar > with the code), instead I will then ask the author (and even, the > maintainer) to do the backport. And that's how the 'request-backport' > email comes. Thanks for this information, it helps to understand how you do it. > So to answer your question. The backport should be easy (when one guy > knows the code enough). If it invovles re-work and changes the behavior > the commit doesn't have, it basically means it's done wrongly. > > That helps? Not really, the issue is more related to fixes which have been published after a re-work of the code, this re-work may have changed internal API/ABI, structures, ... Backporting it becomes like fixing the issue on totally different code inducing several days of work, tests and validation. Should those fixes be backported? Thanks, -- Nélio Laranjeiro 6WIND