Linux Kernel Summit discussions
 help / color / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: ksummit@lists.linux.dev
Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
Date: Wed, 21 Apr 2021 15:22:09 -0400
Message-ID: <20210421152209.68075314@gandalf.local.home> (raw)
In-Reply-To: <afc5664dc2b60f912dd97abfa818b3f7c4237b92.camel@HansenPartnership.com>

On Wed, 21 Apr 2021 11:35:36 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and introduce
> bugs, particularly in older drivers, that don't get detected for a long
> while.  However, the recent events with the University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a truly
> trivial patch and they all need reviewing.
> 
> Our policy in SCSI for a long time has been no trivial patches accepted
> to maintained drivers, and I think that would be a good start if
> adopted kernel wide, but I think the next policy should be no trivial
> bug fix without a pointer to the actual bug report or report from a
> trusted static checker.  This would likely mean we have to create a
> list of trusted static checkers ... obviously 0day and coverity but
> what else?

I take a lot of trivial fixes. I found two that I accepted that were from
umn.edu, and both of them (after a second review) were legitimate fixes.
One was in Greg's revert patch series, which I asked him to not revert, and
the other was me looking at all patches I've received with a Cc to umn.edu
emails, and was from a gmail account (which I'm assuming was someone that
was part of this group).

I have no problem with taking a trivial patch if they are really fixing a
bug. I think what needs to be done here is look at the patches that got in
that were buggy, and see why they got in.

Perhaps the answer is to scrutinize trivial patches more. To me, the only
"trivial" patch is a comment fix, or update to documentation. And even
then, I spend time reviewing it.

If you don't have time to review a patch, then by all means, don't accept
it. Perhaps the answer is simply have a higher bar on what you do accept.

There are a few people that I will accept patches from with out review. But
anyone else, I scrutinize the code before taking it in.


-- Steve


  parent reply index

Thread overview: 153+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21 18:35 James Bottomley
2021-04-21 18:46 ` Christian Borntraeger
2021-04-21 18:51 ` Alexey Dobriyan
2021-04-21 18:53   ` Christian Borntraeger
2021-04-21 19:06 ` Al Viro
2021-04-21 19:14 ` James Bottomley
2021-04-21 19:22 ` Steven Rostedt [this message]
2021-04-21 19:26   ` Kees Cook
2021-04-21 19:32   ` Roland Dreier
2021-04-21 19:55     ` Julia Lawall
2021-04-21 20:28       ` Stephen Hemminger
2021-04-21 20:37         ` Julia Lawall
2021-04-21 20:45           ` Steven Rostedt
2021-04-21 20:50             ` Julia Lawall
2021-04-21 21:03               ` Jiri Kosina
2021-04-21 21:37           ` James Morris
2021-04-22  7:34             ` Geert Uytterhoeven
2021-04-22  7:51               ` Mike Rapoport
2021-04-22  8:45                 ` Christian Brauner
2021-04-22 15:27                   ` Steven Rostedt
2021-04-22  9:39                 ` Mauro Carvalho Chehab
2021-04-22  9:55               ` Mauro Carvalho Chehab
2021-04-22 12:01                 ` Leon Romanovsky
2021-04-22 12:26                   ` Mark Brown
2021-04-22 12:35                     ` Leon Romanovsky
2021-04-22 12:52                       ` Hans Verkuil
2021-04-22 13:33                       ` Mauro Carvalho Chehab
2021-04-22 13:42                         ` Leon Romanovsky
2021-04-22 12:18                 ` Leon Romanovsky
2021-04-22 15:38                   ` Shuah Khan
2021-04-23  9:06                     ` Mauro Carvalho Chehab
2021-04-23 17:17                       ` Leon Romanovsky
2021-04-23 22:41                       ` Shuah Khan
2021-04-22  5:59     ` Christoph Hellwig
2021-04-22  6:28       ` Tomasz Figa
2021-04-22  7:05         ` Al Viro
2021-04-22  7:46           ` Al Viro
2021-04-22  7:06         ` H. Peter Anvin
2021-04-22  7:05       ` Jiri Kosina
2021-04-22 16:05       ` Roland Dreier
2021-04-22 16:24         ` Krzysztof Kozlowski
2021-04-22 18:03       ` Al Viro
2021-04-22 22:35         ` Thomas Gleixner
2021-04-22 22:53           ` Laurent Pinchart
2021-07-20 16:26             ` Kernel sustainability (was Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Daniel Vetter
2021-04-21 19:30 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Jiri Kosina
2021-04-21 20:28   ` Jiri Kosina
2021-04-21 22:18     ` Shuah Khan
2021-04-21 23:17       ` Guenter Roeck
2021-04-21 23:21         ` Shuah Khan
2021-04-21 19:47 ` Dan Carpenter
2021-04-22  9:34   ` Mauro Carvalho Chehab
2021-04-22  9:59     ` Johannes Berg
2021-04-22 10:52       ` Mauro Carvalho Chehab
2021-04-22 12:16         ` Mike Rapoport
2021-04-22 13:41           ` Mauro Carvalho Chehab
2021-04-22 20:15       ` Alexandre Belloni
2021-04-23  0:09         ` Randy Dunlap
2021-04-21 19:49 ` Alexandre Belloni
2021-04-22  2:05 ` Martin K. Petersen
2021-04-22  3:04   ` Joe Perches
2021-04-22 10:13     ` Mauro Carvalho Chehab
2021-04-22 12:07     ` Mark Brown
2021-04-22 16:42     ` Bart Van Assche
2021-04-22 17:58       ` Jiri Kosina
2021-04-22  4:21 ` Leon Romanovsky
2021-04-22  4:56   ` Al Viro
2021-04-22  5:52     ` Leon Romanovsky
2021-04-22  6:05     ` Christoph Hellwig
2021-04-22  6:03   ` Christoph Hellwig
2021-04-22  6:18     ` Leon Romanovsky
2021-04-22  9:20   ` Mauro Carvalho Chehab
2021-04-22 11:34     ` Leon Romanovsky
2021-04-22 13:22       ` Mark Brown
2021-04-22 13:47         ` Leon Romanovsky
2021-04-22 13:51           ` Mark Brown
2021-04-22 14:12         ` Mauro Carvalho Chehab
2021-04-22 14:51           ` Leon Romanovsky
2021-04-22 13:29       ` Steven Rostedt
2021-04-22 13:58         ` Leon Romanovsky
2021-04-22 14:20         ` Rob Herring
2021-04-23  6:04           ` Mauro Carvalho Chehab
2021-04-23  6:46             ` Joe Perches
2021-04-23  7:13               ` Mauro Carvalho Chehab
2021-04-23  7:20                 ` [PATCH RFC] scripts: add a script for sending patches Mauro Carvalho Chehab
2021-04-23 14:52                 ` Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Doug Anderson
2021-04-23 16:03                   ` Mark Brown
2021-04-23 17:12                     ` Leon Romanovsky
2021-04-26 23:50                       ` Simon Glass
2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
2021-04-22 13:08       ` Leon Romanovsky
2021-04-22 13:27         ` Konstantin Ryabitsev
2021-04-22 13:41           ` Leon Romanovsky
2021-04-22 16:28           ` Serge E. Hallyn
2021-04-22 17:56       ` Leon Romanovsky
2021-04-22 18:05         ` backfilling threads with b4 (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Konstantin Ryabitsev
2021-04-23  7:19       ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Greg KH
2021-04-23  7:31       ` Christian Brauner
2021-04-23 18:50         ` Konstantin Ryabitsev
2021-04-22 12:40   ` Mark Brown
2021-04-22 12:54     ` Mike Rapoport
2021-04-22 13:23       ` Mark Brown
2021-04-22 15:19         ` Steven Rostedt
2021-04-22 21:19           ` Thomas Gleixner
2021-04-22 21:36             ` Steven Rostedt
2021-04-22 22:39               ` Thomas Gleixner
2021-04-23  0:26                 ` Joe Perches
2021-04-23  6:15           ` Greg KH
2021-04-23  6:50             ` Dan Williams
2021-04-23  7:13             ` Geert Uytterhoeven
2021-04-23 14:41               ` Shuah Khan
2021-04-23  9:12             ` Michal Hocko
2021-04-22 14:51       ` Laurent Pinchart
2021-04-22 15:14         ` Mike Rapoport
2021-04-22 15:17           ` Laurent Pinchart
2021-04-22 15:35             ` Al Viro
2021-04-22 15:32           ` Shuah Khan
2021-04-22 10:35 ` Mauro Carvalho Chehab
2021-04-22 11:03   ` Sudip Mukherjee
2021-04-22 14:00     ` Steven Rostedt
2021-04-22 14:07       ` Jiri Kosina
2021-04-22 15:31         ` Sudip Mukherjee
2021-04-22 21:33           ` Thomas Gleixner
2021-04-22 20:28     ` Andrew Morton
2021-04-22 20:46       ` Steven Rostedt
2021-04-22 12:32   ` Martin K. Petersen
2021-04-22 15:11     ` Laurent Pinchart
2021-04-22 15:28     ` James Bottomley
2021-04-22 15:35       ` Johannes Berg
2021-04-22 15:36       ` Mark Brown
2021-04-22 15:40         ` James Bottomley
2021-04-23  9:27         ` Dan Carpenter
2021-04-22 13:24   ` Konstantin Ryabitsev
2021-04-22 14:31     ` Mauro Carvalho Chehab
2021-04-22 15:34   ` Shuah Khan
2021-04-22 15:42     ` James Bottomley
2021-04-22 15:48       ` James Bottomley
2021-04-22 15:52         ` Steven Rostedt
2021-04-22 16:08           ` Shuah Khan
2021-04-22 16:13           ` Jan Kara
2021-04-22 17:04             ` Steven Rostedt
2021-04-22 17:08             ` Martin K. Petersen
2021-04-23 11:16               ` Jan Kara
2021-04-23 12:57                 ` Mauro Carvalho Chehab
2021-04-23  7:58           ` Mauro Carvalho Chehab
2021-04-23 10:54             ` Greg KH
2021-04-23 17:09             ` Leon Romanovsky
2021-04-22 16:23         ` Konstantin Ryabitsev
2021-04-22 16:38       ` Bart Van Assche
2021-04-22 16:57         ` Leon Romanovsky
2021-04-22 18:03         ` Jiri Kosina
2021-04-22 21:26           ` Thomas Gleixner
2021-04-22 21:36             ` Jiri Kosina

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=20210421152209.68075314@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=ksummit@lists.linux.dev \
    /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

Linux Kernel Summit discussions

Archives are clonable:
	git clone --mirror https://lore.kernel.org/ksummit/0 ksummit/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ksummit ksummit/ https://lore.kernel.org/ksummit \
		ksummit@lists.linux.dev
	public-inbox-index ksummit

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/dev.linux.lists.ksummit


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git