From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id F11A1530F for ; Tue, 13 Sep 2016 04:39:37 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 12 Sep 2016 19:39:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,326,1470726000"; d="scan'208";a="760062256" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by FMSMGA003.fm.intel.com with ESMTP; 12 Sep 2016 19:39:35 -0700 Date: Tue, 13 Sep 2016 10:40:13 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: "Tan, Jianfeng" , dev@dpdk.org Message-ID: <20160913024013.GI23158@yliu-dev.sh.intel.com> References: <1470297529-100773-1-git-send-email-jianfeng.tan@intel.com> <20160911120906.GV23158@yliu-dev.sh.intel.com> <294735333.lTyYAqE8WY@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <294735333.lTyYAqE8WY@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH 1/2] examples/tep_term: fix offload on VXLAN failure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 02:39:38 -0000 On Mon, Sep 12, 2016 at 11:36:01AM +0200, Thomas Monjalon wrote: > 2016-09-12 08:42, Tan, Jianfeng: > > From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com] > > > FYI, my testrobot caught some errors when this patch is applied. > > > > It's because this patch set has dependency on a previous patch set, which seems a difficult scenario to handle. There's no standard to state the dependency, right? > > No there is no standard to state the dependency. Yes. > We need one. We could. > Actually, there are 3 kinds of dependencies: > - a well know dependency when sending a patch Not quite sure what it is. > - implicit dependency on the HEAD If the HEAD is in one of the DPDK public three (no matter which it is), no issue. My robot will try to apply a patchset to all available trees, one by one, until it succeeds. If the HEAD is a local commit (say, like this case, you made a patch based on some patches from community that haven't been applied yet), it's hard. The only way we can do is that we can do some brute force to get the right combination if no hint given. But I think of no reason to do that: it just brings complexity. So, we could either ask a hint from the author (the tag you mentioned below, or provide a git tree (the alternative I'd suggest, details go below). > (can fail if a conflicting patch is pushed) It also can be fixed quite easily: when failed, it could go few commits backwards, until a right base is found. > - dependency on a specific tree (next-*) Not an issue, as stated above. > > I suggest using: > Depends-on: pw | > Examples: > Depends-on: pw 33000 This one is necessary, both for an auto tools and for some people to have a try. > Depends-on: master 3643b0f > Depends-on: next-net f33e00 I see no good reason to do that, for that's typically where patches apply. And since we have introduced sub-trees, it then should be obvious (for frequent contributors) that if you are making a patch to a PMD driver, you should grab the next-net tree and make patch there. Vice verse, if you got a PMD patch from mailing list and want to have a try, you should try to apply it to the next-net tree. Well, it may fail because the patch author doesn't know this generic rule, that he made patches based on master, you then could have a try with master. Besides, it just adds extra burden to developers: think that we have to add such tag to every patch. > > It won't work well when a patch depends on a pending patch series > because the cover letter has no patchwork identifier. > It will be solved with the next version of patchwork (in few months). > In the meantime, we can point to the first patch of the series. > > Comments/ideas? The alternative I'd suggest is to use git trees. I'm going to add the support of git-tree-based test (hopefully, I could do that this weekend). I'd suggest all frequent contributors to have its own DPDK tree (publicly, say at github, or internally, only works for intel). Every one has a local git, what you need to do is to push your local git to a remote tree. You then tell me the tree URL, my robot will fetch your tree timely. Once you have pushed something, it will start the build test. You could even get a report when it finishes, if you wish. In such case, there is no dependency at all: because the developer already fixed that if any. As stated, it's an alternative. People could choose the one they prefer. --yliu