From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2] scripts: support any legal git revisions as abi validation range Date: Mon, 07 Dec 2015 15:32:11 +0100 Message-ID: <2170557.zTAETIpyLV@xps13> References: <56659309.6010305@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Panu Matilainen Return-path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id DC4F095D2 for ; Mon, 7 Dec 2015 15:33:24 +0100 (CET) Received: by wmww144 with SMTP id w144so152595100wmw.0 for ; Mon, 07 Dec 2015 06:33:24 -0800 (PST) In-Reply-To: <56659309.6010305@redhat.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2015-12-07 16:09, Panu Matilainen: > On 12/03/2015 04:05 PM, Panu Matilainen wrote: > > In addition to git tags, support validating abi between any legal > > gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . " > > "validate-abi.sh master mybranch " etc in addition to > > validating between tags. Makes it easier to run the validator > > for in-development work. > > > > Signed-off-by: Panu Matilainen > > Acked-by: Neil Horman > > --- > > > > v2 changes: > > - update usage and error messages to match new behavior > > - update documentation too (as suggested by John McNamara) > > > > I started wondering why this didn't get applied along with the other > abi-validator changes and noticed this is sitting in patchwork in > "changes requested" state, which doesn't seem right: v2 added the > requested documentation. It seems to be an error. > The discussion around this patch did spur another request (ability to > pass parallel build flags to make) but that's entirely unrelated, so it > shouldn't hold up this one. Yes > I've no intention of sending a v3 of this patch because AFAIK there's > nothing to fix and the make-flags thing does not belong here, but > resetting the state to "new" by myself feels like cheating or something > :) So what's the correct action here? There's preciously little > documentation about expected patchwork workflow and such. It's not cheating. Changing patchwork status and send such an email looks to be the right thing to do. Yes maybe we can improve the contributing guide. Thanks