jeans/motioneyeos
jeans/motioneyeos
1
0
Fork 0
mirror of https://github.com/motioneye-project/motioneyeos.git synced 2025-07-29 22:26:31 +00:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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>
This commit is contained in:
Thomas De Schampheleire 2014-03-02 15:17:22 +01:00 committed by Thomas Petazzoni
parent f07c6c483c
commit 3ebeecbd1c
1 changed files with 40 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
docs/manual/contribute.txt
View File

@ -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 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.
Tested-by:: Indicates that the patch has been tested. It is useful Reviewed-by:: Indicates that you code-reviewed the patch and did your
but not necessary to add a comment about what has been tested. 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