linux-kernel - Re: [tip:core/urgent] MAINTAINERS: Restore "L: linux-kernel@...r.kernel.org" entries

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]

Date:	Wed, 22 Jan 2014 09:30:23 -0800
From:	Joe Perches <joe@...ches.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Ingo Molnar <mingo@...nel.org>, hpa@...or.com,
	alan@...ux.intel.com, acme@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	peterz@...radead.org, paulmck@...ux.vnet.ibm.com,
	akpm@...ux-foundation.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:core/urgent] MAINTAINERS: Restore "L:
 linux-kernel@...r.kernel.org" entries

On Wed, 2014-01-22 at 16:09 +0000, Mark Brown wrote:
> On Wed, Jan 22, 2014 at 05:02:24AM -0800, Joe Perches wrote:
> > So I think the rule should be either every section has
> > an lkml entry or no section does.
[]
> The other option is that we just don't worry if people CC lkml or not -
> for things with a dedicated list it's not super critical that people CC
> to lkml

true

> and in practice doing so would make it even harder to work with
> than it is at the minute.

How?  What is "it" here?

> If they want to do so that's fine and it
> shouldn't be a problem but at this point it's questionable if this is
> something that we actively want to encourge.
> 
> In practice this is exactly what's been happening for years anyway so
> it's not something I'd expect to be controversial.

Perhaps the biggest benefit of cc'ing lkml is
a centralized repository of proposed patches in
https://patchwork.kernel.org/project/LKML/list/

A secondary benefit (sometimes it's just a bother)
is that you get a smallish readership that comments
on semi-frequent code defects and style nits that
enhances overall code quality.

But today, many patches do not hit lkml at all.

netdev, many of the specific arch types, staging,
etc, have separate lists and many patches aren't
cc'd to lkml.

Maybe that's not a bad thing.  Dunno.

I can't think of an easy way to figure out how
often emailed patches are using lists generated by
get_maintainer so I've no idea if this matters.

Perhaps the best argument to cc lkml is still this:

https://lkml.org/lkml/2009/5/27/44

On Tue, 2009-05-26 at 23:00 -0700, Andrew Morton wrote:
> Most subsystem maintainers shed patches like a hobo does dandruff.  If
> it is cc'ed to lkml then there is a decent chance that I will see it
> and will un-lose it.
> 
> This happens probably 100 or more times per kernel release.

cheers, Joe

--
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/