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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|