|
@@ -145,10 +145,47 @@ submissions.
|
|
|
Some tags are used to help following the state of any patch posted on
|
|
|
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
|
|
|
purposes. Please see xref:apply-patches-patchwork[] for more
|