DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shreyansh Jain <shreyansh.jain@nxp.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>, <dev@dpdk.org>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	Igor Ryzhov <iryzhov@nfware.com>, Steve Shin <jonshin@cisco.com>
Subject: Re: [dpdk-dev] Understanding of Acked-By
Date: Fri, 27 Jan 2017 15:54:45 +0530	[thread overview]
Message-ID: <cf51b59d-6c43-5908-7107-fead88192368@nxp.com> (raw)
In-Reply-To: <20170127101304.GA69896@bricha3-MOBL3.ger.corp.intel.com>

On Friday 27 January 2017 03:43 PM, Bruce Richardson wrote:
> On Fri, Jan 27, 2017 at 12:48:06PM +0530, Shreyansh Jain wrote:
>> On Wednesday 25 January 2017 08:28 PM, Thomas Monjalon wrote:
>>> 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.
>>
>> From what I understand, 'Reviewed-by' and 'Acked-by' are the other way
>> around.
>> - Acked-by is intent that 'I agree with change'.
>> - Reviewed-by is 'I vouch for the changes' either through review or
>>   testing or both.
>>
>
> Other way round in what way - compared to proposed by Harry or by
> Thomas? Which do you view as the stronger indication that the patch is
> ok?

Sorry, I should have posted this against Harry's mail rather than
Thomas'.
'Other way round' as compared to Harry's text.
Reviewed-by is a strong indication, in my understanding.

>
> Regards,
> /Bruce
>

-
Shreyansh

  reply	other threads:[~2017-01-27 10:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25 13:53 Van Haaren, Harry
2017-01-25 14:58 ` Thomas Monjalon
2017-01-27  7:18   ` Shreyansh Jain
2017-01-27 10:13     ` Bruce Richardson
2017-01-27 10:24       ` Shreyansh Jain [this message]
2017-01-27 10:32         ` Mcnamara, John
2017-01-27 10:52           ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cf51b59d-6c43-5908-7107-fead88192368@nxp.com \
    --to=shreyansh.jain@nxp.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=harry.van.haaren@intel.com \
    --cc=iryzhov@nfware.com \
    --cc=jonshin@cisco.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).