浏览代码

manual: clarify Tested-by/Reviewed-by/Acked-by tags

This patch updates the manual with more clarified descriptions of tags
Tested-by, Reviewed-by, and Acked-by, as discussed on the Buildroot
developer days in February 2014.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas De Schampheleire 11 年之前
父节点
当前提交
3ebeecbd1c
共有 1 个文件被更改,包括 41 次插入4 次删除
  1. 41 4
      docs/manual/contribute.txt

+ 41 - 4
docs/manual/contribute.txt

@@ -145,10 +145,47 @@ submissions.
 Some tags are used to help following the state of any patch posted on
 Some tags are used to help following the state of any patch posted on
 the mailing-list:
 the mailing-list:
 
 
-Acked-by:: Indicates that the patch can be committed.
-
-Tested-by:: Indicates that the patch has been tested. It is useful
-  but not necessary to add a comment about what has been tested.
+Tested-by:: Indicates that the patch has been tested in one way or
+  another. You are encouraged to specify what kind of testing you
+  performed (compile-test on architecture X and Y, runtime test on
+  target A, ...). This additional information helps other testers and
+  the maintainer.
+
+Reviewed-by:: Indicates that you code-reviewed the patch and did your
+  best in spotting problems, but you are not sufficiently familiar with
+  the area touched to provide an Acked-by tag. This means that there
+  may be remaining problems in the patch that would be spotted by
+  someone with more experience in that area. Should such problems be
+  detected, your Reviewed-by tag remains appropriate and you cannot
+  be blamed.
+
+Acked-by:: Indicates that you code-reviewed the patch and you are
+familiar enough with the area touched to feel that the patch can be
+committed as-is (no additional changes required). In case it later turns
+out that something is wrong with the patch, your Acked-by could be
+considered inappropriate. The difference between Acked-by and
+Reviewed-by is thus mainly that you are prepared to take the blame on
+Acked patches, but not on Reviewed ones.
+
+If you reviewed a patch and have comments on it, you should simply reply
+to the patch stating these comments, without providing a Reviewed-by or
+Acked-by tag. These tags should only be provided if you judge the patch
+to be good as it is.
+
+It is important to note that neither Reviewed-by nor Acked-by imply
+that testing has been performed. To indicate that you both reviewed and
+tested the patch, provide two separate tags (Reviewed/Acked-by and
+Tested-by).
+
+Note also that _any developer_ can provide Tested/Reviewed/Acked-by
+tags, without exception, and we encourage everyone to do this. Buildroot
+does not have a defined group of _core_ developers, it just so happens
+that some developers are more active than others. The maintainer will
+value tags according to the track record of their submitter. Tags
+provided by a regular contributor will naturally be trusted more than
+tags provided by a newcomer. As you provide tags more regularly, your
+'trustworthiness' (in the eyes of the maintainer) will go up, but _any_
+tag provided is valuable.
 
 
 Buildroot's Patchwork website can be used to pull in patches for testing
 Buildroot's Patchwork website can be used to pull in patches for testing
 purposes. Please see xref:apply-patches-patchwork[] for more
 purposes. Please see xref:apply-patches-patchwork[] for more