From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) by dpdk.org (Postfix) with ESMTP id DC82F106A for ; Mon, 16 Jan 2017 11:37:36 +0100 (CET) Received: by mail-lf0-f44.google.com with SMTP id n124so10316506lfd.2 for ; Mon, 16 Jan 2017 02:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=rZxWNfrvNo4sRp/mCexxvSU2IBYpsHmXBwF6sWY0LCg=; b=JtpuMiMoiBE0Lm+rPHyBM5bGhxfe+OTail5EtClNVcuNZ95x42hLpJmXdvst5GXDVh dBHVQju5hvxNmzQE4NAFdV1EJJ5VLq0BfsAYk2uypkSlw/M5P29wfrIv1EFdblECEGdj IN4cmIZew4Bsg4e/Qvun5HE4UILkFZR5M962WcSCJ0m/GEDEpO05TjSwqZyYjc0ZfLXH 1EkxTj00wtX8swIWi0tnouAEoXAtDlxjmlDiEZt7Fw698vzpJ7BsYlDic5RoXN+Uk/Qw RYMaeT6w4Bm9gxFd6qRu3eBAWXZj/1IHovmujJnZ5fwr8evaNM0e8EI4J7z5kJTjNs2M hfYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=rZxWNfrvNo4sRp/mCexxvSU2IBYpsHmXBwF6sWY0LCg=; b=r0zR9OxB0KbnvODWTOd7yt0QnsVXtJi3/US42nIIL4BveHvE2sDSAcxaFys9Pv2UuR 15l99HLi5HsF7oWhnG61G7o08sQjRLCXOeJYSzdyzgVtMVnNU/k1GRGWg2c74Ce5ZYxR am54xo/BU8ZwHHaFhMMlfLrFWPvCKtez1aIrfno/W/lBENFeEbD/62gtf6y0oQyvU91l +wMOeuGqknT/BAA59t7i8tB/0+eTsLWVtggCATligbZ44wsjETLPyss83C7Fp+3wxhLp lAXziEU8URrkluHeUuhI3reWSGl3l/nzKjoVaVzgI7QaiDD3sjE+Qzk0vfBx9ZVdR7rn rw7w== X-Gm-Message-State: AIkVDXKfMq4QXCb5wbPOL01hRSJzRZ+cKP8P37fIZTiaW40RgN5bGb0HSUjDPTDkO+pZ2i7r X-Received: by 10.46.78.26 with SMTP id c26mr2767419ljb.39.1484563056417; Mon, 16 Jan 2017 02:37:36 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id s7sm2300588lja.27.2017.01.16.02.37.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 02:37:35 -0800 (PST) From: Thomas Monjalon To: Yuanhan Liu Cc: Ferruh Yigit , dev@dpdk.org Date: Mon, 16 Jan 2017 11:37:34 +0100 Message-ID: <1635933.WUEFBCc6hf@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170116095152.GQ9770@yliu-dev.sh.intel.com> References: <1479768194-6255-1-git-send-email-thomas.monjalon@6wind.com> <1b249c77-5685-8492-6f6b-3478a2731267@intel.com> <20170116095152.GQ9770@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] scripts: check cc stable mailing list in commit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 10:37:37 -0000 2017-01-16 17:51, Yuanhan Liu: > On Wed, Nov 30, 2016 at 02:54:14PM +0000, Ferruh Yigit wrote: > > On 11/21/2016 10:43 PM, Thomas Monjalon wrote: > > > Add a check for commits fixing a released bug. > > > Such commits are found thanks to scripts/git-log-fixes.sh. > > > They must be sent CC: stable@dpdk.org. > > > In order to avoid forgetting CC, this mail header can be written > > > in the git commit message. > > > > > > Signed-off-by: Thomas Monjalon > > > > I think this is useful, thanks for the patch. > > Yes, it is. Thanks! (Sorry for late reply; hope it's not too late). > > > > +[ -z "$bad" ] || printf "Should CC: stable@dpdk.org\n$bad\n" > > > > This is good for developer, but since "CC: xx" tags removed when patch > > applied, > > Again, I'd suggest to __not__ remove such tag. Firstly, why bother? And > I will talk why this tag should be kept, as a stable tree maintainer. The drawback of keeping CC: in the mainline tree would be to give the wrong feeling that only the commits having that tag are in the stable tree. > At the beginning, when people are not used to add "cc: stable" tag, I used > to pick bug fix commits from master by something like: list all bug fixing > patches and pick those that appliable to previous release. > > Later, kudos to Thomas, who wrote an handy script (git-log-fixes.sh) to > do both, it indeeded make my life much easier. But it's still not enough. > > It lists a lot of patches (206 fix patches, while 728 in total: the > ratio is near 30%): > > $ devtools/git-log-fixes.sh v16.07..v16.11 | wc -l > 206 > > $ git rev-list v16.07..v16.11 | wc -l > 728 > > Thus I dropped few of them, manually, resulting to 130 (still looks like > a big number to me): I do not think it is a so big number. > > $ git rev-list v16.07..v16.07.2 | wc -l > 130 > > The policy I would expect is, leave this tag as it is, I then will apply > all of them to a stable branch: I will no longer do the picking job. Instead, > I may just need handle those can't apply cleanly and ask the author to > do backport. > > It would be do-able now, as I saw a lot of people are getting used to add > such tag. And even not, I saw those kind committers do that for them. The kind committers were adding CC: in their email reply. You would like we add CC: also in the git tree before committing, right? It put another responsibility on committers. When the stable tag is forgotten by the author, it is easy to forget adding it in the commit. And when it is pushed, it is too late. But we can still fix this neglecting by sending an email to stable@dpdk.org. That's why I think the most reliable source of explicit tagging is the stable mailing list, not the mainline git tree. > Besides, if there is already an explicit way, why should we stick on the > implicit way? Because the explicit way is not 100% proof. I think we still need to check manually to avoid missing too many fixes. The other way (that you are advocating) means that we accept to miss some fixes and it will enforce the community to become better and better to manage that. I can agree to your way of thinking. I just want to make it 100% clear to everyone and read the feedbacks. My conclusion: the work of stable maintainer should be simpler and better automated. If we miss some fixes because of the automated process, it means we must be better in this process :) The most reliable source of trust in this automated process should be the list of patches appearing on the stable mailing list at any time (on first send or after it has been merged in the mainline).