On Sun, 12 Jan 2025, Neal Gompa <neal@xxxxxxxxx> wrote: > On Sun, Jan 12, 2025 at 10:30 AM Miguel Ojeda <ojeda@xxxxxxxxxx> wrote: >> >> Newcomers to the kernel need to learn the different tags that are >> used in commit messages and when to apply them. Acked-by is sometimes >> misunderstood, since the documentation did not really clarify (up to >> the previous commit) when it should be used, especially compared to >> Reviewed-by. >> >> The previous commit already clarified who the usual providers of Acked-by >> tags are, with examples. Thus provide a clarification paragraph for >> the comparison with Reviewed-by, and give a couple examples reusing the >> cases given above, in the previous commit. >> >> Acked-by: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> >> Acked-by: Dan Williams <dan.j.williams@xxxxxxxxx> >> Signed-off-by: Miguel Ojeda <ojeda@xxxxxxxxxx> >> --- >> Documentation/process/submitting-patches.rst | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst >> index c7a28af235f7..7b0ac7370cb1 100644 >> --- a/Documentation/process/submitting-patches.rst >> +++ b/Documentation/process/submitting-patches.rst >> @@ -480,6 +480,12 @@ mergers will sometimes manually convert an acker's "yep, looks good to me" >> into an Acked-by: (but note that it is usually better to ask for an >> explicit ack). >> >> +Acked-by: is also less formal than Reviewed-by:. For instance, maintainers may >> +use it to signify that they are OK with a patch landing, but they may not have >> +reviewed it as thoroughly as if a Reviewed-by: was provided. Similarly, a key >> +user may not have carried out a technical review of the patch, yet they may be >> +satisfied with the general approach, the feature or the user-facing interface. >> + >> Acked-by: does not necessarily indicate acknowledgement of the entire patch. >> For example, if a patch affects multiple subsystems and has an Acked-by: from >> one subsystem maintainer then this usually indicates acknowledgement of just >> -- >> 2.48.0 >> > > This doesn't make sense as a distinction. What defines "thoroughly"? > To be honest, I think you should go the other way and become okay with > people sending Reviewed-by tags when people have looked over a patch > and consider it good to land. > > To me, Acked-by mostly makes sense as a tag for people who *won't* > review the code, not for those who *will*. Blending Acked-by and > Reviewed-by just creates confusion. As a maintainer, I mostly use Acked-by for two slightly different cases: 1) I've seen the patch. I have no objections to it being merged, I approve of it. I haven't done a detailed review of it. Additionally, I may indicate whether a detailed review (by someone else) is required, or whether I think the ack is sufficient for merging. 2) I'm fine with the patch to the area I maintain being merged via some other maintainers' repositories. I may or may not have also given my Reviewed-by in this case, which alone is not an approval to merge via other trees. I think this pretty much aligns with the patch series. BR, Jani. -- Jani Nikula, Intel