From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 4665EDE5 for ; Mon, 16 Jan 2017 15:43:55 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP; 16 Jan 2017 06:43:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,239,1477983600"; d="scan'208";a="54461384" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga006.fm.intel.com with ESMTP; 16 Jan 2017 06:43:52 -0800 Date: Mon, 16 Jan 2017 22:46:09 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: Ferruh Yigit , dev@dpdk.org Message-ID: <20170116144609.GE10293@yliu-dev.sh.intel.com> References: <1479768194-6255-1-git-send-email-thomas.monjalon@6wind.com> <1635933.WUEFBCc6hf@xps13> <20170116111904.GC10293@yliu-dev.sh.intel.com> <4183619.bfC9sCq4mC@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4183619.bfC9sCq4mC@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) 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 14:43:55 -0000 On Mon, Jan 16, 2017 at 03:26:03PM +0100, Thomas Monjalon wrote: > > > > Besides, if there is already an explicit way, why should we stick on the > > > > implicit way? > > > > > > Because the explicit way is not 100% proof. > > > > Yes, but I think it will be close to "100%" as time moves forward, when all > > people are really used to add "cc: stable" tag, when there are just few need > > to be added manually by the kind committers, when people know that the chance > > your patch will not be in a stable release will be MUCH higher if you don't > > do that. > > > > > I think we still need to check manually to avoid missing too many fixes. > > > > I agree. It's un-avoidable, especially in the first stage like where we are > > now. But my purpose is to create some solid working styles, so that it would > > be eaiser and convenient for everyone who wants to take such role in future. > > > > That said, I will still look the git history, to do some extra manual check. > > I may still use the script (git-log-fixes.sh) for a while. But the long goal > > is to get rid of it, because there are so many things you have to check > > mannually with that. > > > > > 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). > > > > As stated, it's really hard: despite there are many versions, the biggest > > difficult is commiters like to change the subject a bit. For example, here > > is one work from myslef :/ > > > > [PATCH] vhost: Introduce vhost-user's REPLY_ACK feature > > > > That's the one you see in the mailing list, and following is what you will > > see in the git (after my twist): > > > > vhost: introduce reply ack feature > > OK I understand your long term goal. Thank you! > I suggest to move forward by explaining this need in the contribution guide. Sure. My plan was, - make a contribution guide - update the roadmap The reason I have postoned the two for a while is I have few more thoughts to refine the stable release a bit, which I will give more details in another email in days. --yliu