All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: ksummit-discuss@lists.linuxfoundation.org
Subject: [Ksummit-discuss] [MAINTAINERS SUMMIT] Keeping reviews meaningful
Date: Sat, 6 Jul 2019 16:27:38 +0200	[thread overview]
Message-ID: <20190706142738.GA6893@kunai> (raw)

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]


In the parts of the Kernel I work with, reviews are usually given by a plain
tag. I think this is not enough to keep a good code quality, so I'll start with
my theses first:

1) we need a better distinction between Acked-by: and Reviewed-by: and encourage
   stricter use of that

2) Reviewed-by should have a description of the review done (and the review not
   done)

3) trivial patches should rather get Acked-by

4) failing the above should be constructively criticized


Some more words about each item:

1) I am definitely not striving for a clear line, that's impossible. Yet, from
what I experience, the overlap between the two became large. It reduces the
extra value a Reviewed-by should have.

2) A short paragraph will usually do. Of course, trust helps a lot, but it
doesn't solve everything. Trusted people can be in a hurry, too, etc. And for
people I don't know, the plain tag doesn't tell me much. Examples for short
descriptions: "I can't say much about the media part, but the I2C part is
proper" or "I also checked the documentation and I think this is a good
approach to overcome the issue" or "All my concerns in the preceding
discussions have been addressed"

3) Again, no hard line on what is trivial can be made. Still, I think it will
add to the extra value of a review tag if it is only applied to something which
is non-trivial, so we should try to have a better distinction.

4) We are in such a need for people reviewing that it can be challenging for
maintainers to be picky about reviews (you can partly include me here). A
kernel-wide movement aiming for a better distinction between ack (= looks good)
and review helps both maintainers and developers, I think.

These things will hopefully help me as a maintainer to better evaluate trust
for a patch based on the tags given. So, I will try that in the I2C subsystem.
I would prefer, though, not to be an island but to have something which is
accepted kernel-wide.

Disclaimer: I am mainly active in the drivers section of Linux. If reviews are
handled differently in other parts, I am all ears.

Well, I am all ears, anyhow. Opinions?

Kind regards,

  Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2019-07-06 14:27 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-06 14:27 Wolfram Sang [this message]
2019-07-06 16:52 ` [Ksummit-discuss] [MAINTAINERS SUMMIT] Keeping reviews meaningful 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
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=20190706142738.GA6893@kunai \
    --to=wsa@the-dreams.de \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /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.