From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [142.44.231.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0EF582F9B for ; Thu, 22 Apr 2021 04:56:31 +0000 (UTC) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lZRO8-007Dkk-SM; Thu, 22 Apr 2021 04:56:28 +0000 Date: Thu, 22 Apr 2021 04:56:28 +0000 From: Al Viro To: Leon Romanovsky Cc: James Bottomley , ksummit@lists.linux.dev Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Message-ID: References: X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote: > On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley 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. > > While we are talking about policies, I would like to raise another bad > practice that is done by even seasoned developers - sending patches with > carefully crafted and filtered TO and CC. > > This practice causes to get out of context patches without ability to > see whole picture and the worse part that it divides feedback to > "islands" without ability to agree or disagree with the feedback. Suppose you have a 60-patch series, with 56 in fs/*.c (and related headers in include/linux) and 4 - in arch/*/include/asm/*; should e.g. MIPS folks get spammed with the entire thing, just because one patch consolidates some ifdefs?