From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 60F6ADE5 for ; Wed, 25 Jan 2017 15:58:55 +0100 (CET) Received: by mail-wm0-f44.google.com with SMTP id c85so30022720wmi.1 for ; Wed, 25 Jan 2017 06:58:55 -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=W5yO6YXaEXNuhQ4aUlNDyhAuwihUTn/K/SUr/NWNSgI=; b=0oVVsHVquTnu8p152c1ieo/8jOFuBQEVSfGgi7enpCB1UHMLZWRTsvfZQj2dHrGUSp CaI3xMDnM7+mpL/bDcv1MLTuiHy66sW//746ewo6t8ICkb9i58BgRlJT+FAyyFl7z7rP Yd0mnuuuMD8BF6D2Ty+y0okiN4zOSQ3bPDC/efrY6JIDcFup1Z0GFCloT8YGPzh0DGj8 pe2jqDRv2Ze3vkKxZkDyYLxY9kVXZNd3rSgFb6aMpeoxVRS9oxikoOI9pATc3mIqrFpZ /TEcav6c/D1wouQjZddT5ckDzpHq+ZCnTugqzAEYnNCLd7sGjKvC7ZJ09mdltlK6lT6A jkKA== 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=W5yO6YXaEXNuhQ4aUlNDyhAuwihUTn/K/SUr/NWNSgI=; b=q7zuj4mFxOl9jXOw3M93o4fl7jbPZ34N8AREFvZ+4w10ikdiNGRCtd6rNxCYA1QKKn UaLO2lTGCah3axR3ow1yhs0614gtjJGpqYhdp56BgBQD8aNmt8+f9AIIrwJLeVzTpqnS z9EOKJgkRuA380CrPTEYprzbc1CbFEoUBRwgzuZ/3mSc6aJqNW+DVdMbxNQU0v5GxRf6 36ZpBjPYNH8hSMlHdSOguYDiF9IHJHJ4qcbwN9eWsliZPYGeZxtk/+cJzVvwPKQIsduP 0//kLtqhRjxRMJOoxkjRrGCJotNAstPIFNHbHdBvYOxVG+HWERDxiY2sXxMR+NLxG3th fIsg== X-Gm-Message-State: AIkVDXLIRCvxxUcrPGV7ZTwlMEwkujjRKpoy+9EGeDPiMNqBBoR4gruGvQcFoOJKu+4DOoqv X-Received: by 10.223.136.109 with SMTP id e42mr33820646wre.14.1485356334978; Wed, 25 Jan 2017 06:58:54 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id y97sm1104278wmh.24.2017.01.25.06.58.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 06:58:53 -0800 (PST) From: Thomas Monjalon To: "Van Haaren, Harry" Cc: dev@dpdk.org, "Yigit, Ferruh" , Igor Ryzhov , Steve Shin Date: Wed, 25 Jan 2017 15:58:52 +0100 Message-ID: <2358632.GCFl4gnRC2@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Understanding of Acked-By 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: Wed, 25 Jan 2017 14:58:55 -0000 2017-01-25 13:53, Van Haaren, Harry: > There was an idea (from Thomas) to better document the Acked-by and Reviewed-By in the above thread, which I think is worth doing to make the process clearer. I'll kick off a thread*, and offer to submit a patch for the documentation when a consensus is reached. > > > The question that needs to be addressed is "What is the most powerful signoff to add as somebody who checked a patch?" I do not see the benefit of knowing the most powerful. Anyway, the most powerful tags are done by trusted people. And people are trusted after delivering good reviews or patches ;) The question should be "How to use the tags?" > The documentation mentions Acked, Reviewed, and Tested by[1], as signoffs that can be commented on patches. The Review Process[2] section mentions Reviewed and Tested by, but nowhere specifically states what any of these indicate. > > Offered below is my current understanding of the Acked-by; Reviewed-by; and Tested-by tags, in order of least-powerful first: > > > 3) Tested-by: (least powerful) > - Indicates having passed testing of functionality, and works as expected for Tester > - Does NOT include full code review (instead use Reviewed by) > - Does NOT indicate that the Tester understands architecture (instead use Acked by) > > > 2) Reviewed-by: > - Indicates having passed code-review, checkpatch and compilation testing by Reviewer Compilation testing is done by the CI. The reviewer must just check the results. > - Does NOT include full testing of functionality (instead use Tested-by) > - Does NOT indicate that the Reviewer understands architecture (instead use Acked by) I disagree here. The reviewer must understand the impacts of the patch. That's why a Reviewed-by tag is really strong. > 1) Acked-by: (most powerful) > - Indicates Reviewed-by, but also: A maintainer may want to approve the intent without doing a full review, especially if he trusts the author or the reviewers. That's why I think Acked-by should not include Reviewed-by. If a maintainer does a full review, he should use Reviewed-by instead of Acked-by. > - Acker understands impact to architecture (if any) and agrees with changes > - Acker has performed runtime sanity check Not sure about this one. Personnaly I give some Acks without testing sometimes. We may add a Tested-by to indicate we made some tests. > - Requests "please merge" to maintainer Yes, "please merge" to tree maintainer (committer). > - Level of trust in Acked-by based on previous contributions to DPDK/networking community The level of trust applies to any tag or comment. > The above is a suggested interpretation, alternative interpretations welcomed. Thanks Harry