From: Paul Mundt <lethal@linux-sh.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Joe Perches <joe@perches.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 16/18] MAINTAINERS - Remove L: linux-kernel@vger.kernel.org from all but "THE REST"
Date: Wed, 27 May 2009 10:33:03 +0900 [thread overview]
Message-ID: <20090527013303.GB8979@linux-sh.org> (raw)
In-Reply-To: <fa686aa40905232151g5ed5bcc8t2f19d63ace2277e7@mail.gmail.com>
On Sat, May 23, 2009 at 10:51:24PM -0600, Grant Likely wrote:
> On Sat, May 23, 2009 at 10:39 PM, Joe Perches <joe@perches.com> wrote:
> > On Sat, 2009-05-23 at 22:28 -0600, Grant Likely wrote:
> >> On Sat, May 23, 2009 at 9:22 PM, Joe Perches <joe@perches.com> wrote:
> >> > On Sat, 2009-05-23 at 21:18 -0600, Grant Likely wrote:
> >> >> Really? ?That makes the assumption that lack of an "L:" tag is
> >> >> equivalent to an "L:linux-kernel" tag, which IMNSHO I don't believe is
> >> >> true.
> >> > Documentation/SubmittingPatches
> >> > 6) Select your CC (e-mail carbon copy) list.
> >> > Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
> >> Is that actually true in practice? ?At least on linuxppc-dev, very few
> >> patches are cc'd to lkml. ?I don't remember ever being prompted to cc
> >> lkml on all patches, and I haven't been prompting others to do so.
> >
> > Hi Grant.
> >
> > I think cc:ing lkml should be the default for patches.
>
> Do subsystem maintainers think so? Unless they do (and tell others
> so), I don't think it will actually happen. Until that point, I don't
> think the L:linux-kernel lines should be removed.
>
Ultimately it should come to common sense. If you are only touching
subsystem or architecture-specific code and it's unlikely anyone on l-k
is going to care, or have much to add to it, then there really isn't a
lot of point in mindlessly Cc-ing the list on every change.
The signal to noise ratio on l-k is already limping along without
encouraging people to submit every random patch for review. If you are
told to resubmit and add the list and random people to the Cc, or if you
are at all in doubt over a patch submission, then naturally cc'ing l-k is
the way to go.
In practice we are well beyond the stage of monitoring every single
patch that is going in anyways, these days you are more likely to find an
obscure change in git than you are on the list. If a process problem
arises, it is usually quite easily corrected.
People might disagree, but at least based on the architecture lists, it
is more the exception than the norm that l-k is CCed, and it's only the
odd times when a discussion carries over and someone has to either
summarize or point at archives.
Conversely, if you need to read SubmittingPatches to figure out how to
submit a patch, yes, you are probably better off CCing l-k just to be on
the safe side. As a blanket policy though it makes no sense.
next prev parent reply other threads:[~2009-05-27 1:33 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-24 2:37 [PATCH 00/18] MAINTAINERS and scripts/get_maintainer.pl updates Joe Perches
2009-05-24 2:37 ` [PATCH 01/18] scripts/get_maintainer.pl - Output first field only in mailing lists and after maintainers Joe Perches
2009-05-24 2:37 ` [PATCH 02/18] scripts/get_maintainer.pl - Better fix for subscriber-only mailing lists Joe Perches
2009-05-24 2:37 ` [PATCH 03/18] scripts/get_maintainer.pl - improve --git-chief-penquins (Linus Torvalds) filtering Joe Perches
2009-05-24 2:37 ` [PATCH 04/18] scripts/get_maintainer.pl - Warn on missing git or git repository Joe Perches
2009-05-24 2:37 ` [PATCH 05/18] scripts/get_maintainer.pl - support M: lines with names and multiple entries per M: line Joe Perches
2009-05-24 2:37 ` [PATCH 06/18] scripts/get_maintainer.pl - Better email name quoting Joe Perches
2009-05-24 2:37 ` [PATCH 07/18] scripts/get_maintainer.pl - Support both "P:/M:" and integrated "M:" lines Joe Perches
[not found] ` <20090526144141.570594cf.akpm@linux-foundation.org>
[not found] ` <1243455722.27337.65.camel@Joe-Laptop.home>
[not found] ` <20090527151510.fb773db6.akpm@linux-foundation.org>
2009-06-01 17:45 ` Script to integrate MAINTAINERS P: and M: lines Joe Perches
2009-06-02 9:12 ` Pavel Machek
2009-06-05 21:47 ` Sam Ravnborg
2009-06-05 22:57 ` Joe Perches
2009-05-24 2:37 ` [PATCH 08/18] scripts/get_maintainer.pl - Don't print maintainers when not requested Joe Perches
2009-05-24 2:37 ` [PATCH 09/18] scripts/get_maintainer.pl - Allow 8 bit characters in email addresses Joe Perches
2009-05-24 2:37 ` [PATCH 10/18] scripts/get_maintainer.pl - change "die" to "warn" when command line file is not a patch Joe Perches
2009-05-24 2:37 ` [PATCH 11/18] MAINTAINERS - Swap mismarked ECRYPT FS M: and P: entries Joe Perches
2009-05-24 2:37 ` [PATCH 12/18] MAINTAINERS - Pair EDAC-E752X P: and M: entries Joe Perches
2009-05-24 2:37 ` [PATCH 13/18] MAINTAINERS - Add file patterns to "THE REST" Joe Perches
2009-05-24 2:37 ` [PATCH 14/18] MAINTAINERS - Update M32R file patterns after rename Joe Perches
2009-05-24 2:37 ` [PATCH 15/18] MAINTAINERS - Mark ALSA lists as moderated Joe Perches
2009-05-24 2:37 ` [PATCH 16/18] MAINTAINERS - Remove L: linux-kernel@vger.kernel.org from all but "THE REST" Joe Perches
2009-05-24 3:18 ` Grant Likely
2009-05-24 3:22 ` Joe Perches
2009-05-24 4:28 ` Grant Likely
2009-05-24 4:39 ` Joe Perches
2009-05-24 4:51 ` Grant Likely
2009-05-24 4:58 ` Joe Perches
2009-05-27 1:33 ` Paul Mundt [this message]
2009-05-27 5:38 ` Joe Perches
2009-05-27 5:50 ` Paul Mundt
2009-05-27 6:00 ` Andrew Morton
2009-05-27 6:02 ` Paul Mundt
2009-05-27 16:12 ` Joe Perches
2009-05-24 10:42 ` Mark Brown
2009-05-26 23:42 ` Paul E. McKenney
2009-05-27 18:18 ` [PATCH] MAINTAINERS: Add Paul McKenney to RCU and RCUTORTURE Joe Perches
2009-05-27 21:03 ` Paul E. McKenney
2009-05-24 2:37 ` [PATCH 17/18] MAINTAINERS - Mention scripts/get_maintainer.pl in the preface Joe Perches
2009-05-24 2:37 ` [PATCH 18/18] MAINTAINERS - Add file pattern to CISCO FCOE HBA DRIVER Joe Perches
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=20090527013303.GB8979@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=akpm@linux-foundation.org \
--cc=grant.likely@secretlab.ca \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox