lkml.org 
[lkml]   [2009]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 16/18] MAINTAINERS - Remove L: from all but "THE REST"
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.


\
 
 \ /
  Last update: 2009-05-27 03:37    [W:0.074 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site