lkml.org 
[lkml]   [2018]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
From
Date
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



\
 
 \ /
  Last update: 2018-10-24 10:40    [W:0.050 / U:0.240 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site