All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Keeping reviews meaningful
Date: Mon, 15 Jul 2019 12:58:00 -0300	[thread overview]
Message-ID: <20190715125800.22a9a979@coco.lan> (raw)
In-Reply-To: <20190708115949.GC1050@kunai>

Em Mon, 8 Jul 2019 13:59:50 +0200
Wolfram Sang <wsa@the-dreams.de> escreveu:

> Hi Geert,
> 
> > > 1) we need a better distinction between Acked-by: and Reviewed-by: and encourage
> > >    stricter use of that  
> > 
> > Before we had "Reviewed-by", "Acked-by" meant "looks OK to me".
> > Then we got "Reviewed-by" for more thorough reviews.  
> 
> This is what still makes most sense to me. You can express e.g. that you
> like a patch series and approve the general approach taken but haven't
> gone for the gory details -> Acked-by (a short explaining paragraph
> would make sense, then, too)
> 
> Is that old fashioned?
> 
> Acked-by only for maintainers doesn't make sense to me. Neiher does when
> Acked-by has a different meaning for maintainers and non-maintainers.

On my case, when I receive an Acked-by, I assume that this came
from a maintainer (either a subsystem maintainer or a driver
maintainer) - as I expect that non-maintainers (and reviewers)
will either send me a reviewed-by or a tested-by.

When a review a code that will be merged via someone's else tree,
I usually either give:

- Acked-by - if it is something that touches the subsystem
  I maintain and will be merged via some other tree, but I 
  didn't make a comprehensive review;

- Reviewed-by - if I did a comprehensive review. I can either
  be the maintainer or not of the files touched by the patch.

So, I usually expect the others do about the same.

Looking at Documentation/process/5.Posting.rst:

	 - Acked-by: indicates an agreement by another developer (often a
	   maintainer of the relevant code) that the patch is appropriate for
	   inclusion into the kernel.

	 - Reviewed-by: the named developer has reviewed the patch for correctness;
	   see the reviewer's statement in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
	   for more detail.

I guess the descriptions are already enough to describe those
tags.

Thanks,
Mauro

  reply	other threads:[~2019-07-15 15:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-06 14:27 [Ksummit-discuss] [MAINTAINERS SUMMIT] Keeping reviews meaningful Wolfram Sang
2019-07-06 16:52 ` Leon Romanovsky
2019-07-06 17:17   ` Wolfram Sang
2019-07-08 10:47     ` Jan Kara
2019-07-08 11:47       ` Wolfram Sang
2019-07-15 16:11     ` Mauro Carvalho Chehab
2019-07-08 11:21 ` Geert Uytterhoeven
2019-07-08 11:59   ` Wolfram Sang
2019-07-15 15:58     ` Mauro Carvalho Chehab [this message]
2019-07-15 17:00       ` Theodore Y. Ts'o
2019-07-15 17:11         ` Mauro Carvalho Chehab
2019-07-16 21:26         ` Wolfram Sang
2019-08-17 21:35         ` Paul Walmsley
2019-08-19  6:57           ` Jan Kara
2019-08-19  7:06             ` Jiri Kosina
2019-08-19  7:06             ` Julia Lawall
2019-08-19  8:04               ` Jan Kara
2019-08-19  8:13                 ` Julia Lawall
2019-08-20 10:22                   ` James Bottomley
2019-08-19  8:26             ` Thomas Gleixner
2019-08-19 16:16               ` Christian Brauner
2019-08-19 19:04                 ` Thomas Gleixner
2019-08-19 21:03                   ` Christian Brauner
2019-07-08 14:57   ` Mark Brown
2019-07-14  9:35 ` Jonathan Cameron
2019-07-14 10:13   ` Thomas Gleixner
2019-07-15  9:10     ` Rafael J. Wysocki
2019-07-16 21:16     ` Wolfram Sang
2019-07-16 21:57       ` Olof Johansson
2019-07-16 22:27         ` Thomas Gleixner
2019-07-17  3:59           ` Randy Dunlap
2019-07-17  7:31             ` Wolfram Sang
2019-07-17 16:05               ` Linus Walleij
2019-07-17 16:40                 ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190715125800.22a9a979@coco.lan \
    --to=mchehab+samsung@kernel.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.