lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090527013303.GB8979@linux-sh.org>
Date:	Wed, 27 May 2009 10:33:03 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Joe Perches <joe@...ches.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 16/18] MAINTAINERS - Remove L: linux-kernel@...r.kernel.org 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@...ches.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@...ches.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@...r.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ