From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63C42C67863 for ; Wed, 24 Oct 2018 08:39:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2C840206B5 for ; Wed, 24 Oct 2018 08:39:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C840206B5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=perches.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727466AbeJXRGc (ORCPT ); Wed, 24 Oct 2018 13:06:32 -0400 Received: from smtprelay0032.hostedemail.com ([216.40.44.32]:52395 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726732AbeJXRGc (ORCPT ); Wed, 24 Oct 2018 13:06:32 -0400 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 5E838180585F3; Wed, 24 Oct 2018 08:39:21 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-HE-Tag: board99_34568bc2f9c0a X-Filterd-Recvd-Size: 3639 Received: from XPS-9350.home (unknown [47.151.153.53]) (Authenticated sender: joe@perches.com) by omf18.hostedemail.com (Postfix) with ESMTPA; Wed, 24 Oct 2018 08:39:19 +0000 (UTC) Message-ID: <02a1bfc2eed324f3d03aa4a7b5eb6fde4e4a3bdd.camel@perches.com> Subject: Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic. From: Joe Perches To: Michal Hocko Cc: Arun KS , Kees Cook , Konstantin Khlebnikov , LKML , linux-mm , Minchan Kim , Arun Sudhilal , Greg Kroah-Hartman , Andrew Morton Date: Wed, 24 Oct 2018 01:39:18 -0700 In-Reply-To: <20181024082312.GD18839@dhcp22.suse.cz> References: <1540229092-25207-1-git-send-email-arunks@codeaurora.org> <15247f54-53f3-83d4-6706-e9264b90ca7a@yandex-team.ru> <7a4fcbaee7efb71d2a3c6b403c090db4@codeaurora.org> <20181024061546.GY18839@dhcp22.suse.cz> <0e1fc40af360ed55fd32784f6973af5940232f99.camel@perches.com> <20181024082312.GD18839@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.30.1-1build1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-10-24 at 10:23 +0200, Michal Hocko wrote: > On Tue 23-10-18 23:26:16, Joe Perches wrote: > > On Wed, 2018-10-24 at 08:15 +0200, Michal Hocko wrote: > > > On Wed 24-10-18 10:47:52, Arun KS wrote: > > > > On 2018-10-24 01:34, Kees Cook wrote: > > > [...] > > > > > Thank you -- I was struggling to figure out the best way to reply to > > > > > this. :) > > > > I'm sorry for the trouble caused. Sent the email using, > > > > git send-email --to-cmd="scripts/get_maintainer.pl -i" > > > > 0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch > > > > > > > > Is this not a recommended approach? > > > > > > Not really for tree wide mechanical changes. It is much more preferrable > > > IMHO to only CC people who should review the intention of the change > > > rather than each and every maintainer whose code is going to be changed. > > > This is a case by case thing of course but as soon as you see a giant CC > > > list from get_maintainer.pl then you should try to think twice to use > > > it. If not sure, just ask on the mailing list. > > > > Generally, it's better to use scripts to control > > the --to-cmd and --cc-cmd options. > > I would argue that it is better to use a common sense much more than > scripts. Common sense isn't common. Perhaps you could describe some guidelines you use to determine what you think is sensible to send patches to maintainers and reviewers and appropriate mailing lists. Then compare those to the rules in the scripts I suggested. My suggestions: o send to all top-level listed maintainers and reviewers in MAINTAINERS for the specific files in a patch o cc all maintainers and reviewers that are upstream paths for the files in a patch o cc all the upstream mailing lists for the files in the patch. o do not generally use git-history to exclude authors of patches like drive-by/whitespace cleanups Other advanced possibilities for patches that modify specific and perhaps complex logic blocks: o cc the people that are not maintainers that have modified the specific blocks or functions