[dpdk-dev] Understanding of Acked-By
Van Haaren, Harry
harry.van.haaren at intel.com
Wed Jan 25 14:53:12 CET 2017
( Was [dpdk-dev] [PATCH v4] ethdev: fix MAC address replay, CC-ed are participants of that thread http://dpdk.org/ml/archives/dev/2017-January/056278.html )
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?"
The documentation mentions Acked, Reviewed, and Tested by, as signoffs that can be commented on patches. The Review Process 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)
- Indicates having passed code-review, checkpatch and compilation testing by Reviewer
- Does NOT include full testing of functionality (instead use Tested-by)
- Does NOT indicate that the Reviewer understands architecture (instead use Acked by)
1) Acked-by: (most powerful)
- Indicates Reviewed-by, but also:
- Acker understands impact to architecture (if any) and agrees with changes
- Acker has performed runtime sanity check
- Requests "please merge" to maintainer
- Level of trust in Acked-by based on previous contributions to DPDK/networking community
The above is a suggested interpretation, alternative interpretations welcomed.
* Apologies for the slightly bike-shed topic
More information about the dev