On Fri, 20 Sep 2019, Doug Anderson <diand...@chromium.org> wrote: > On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart > <laurent.pinch...@ideasonboard.com> wrote: >> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up >> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding >> LKML automatically is a good idea if other mailing lists are already >> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it >> when no other mailing list is appropriate certainly makes sense). > > Please don't do this, as it means the patch won't be findable on the > "LKML" patchwork instance at: > > https://lore.kernel.org/patchwork/project/lkml/list/ > > Having LKML copied on all patches is also nice because it makes it > easier to respond to a patch that was posted to a list you didn't > subscribe to. I subscribe to LKML and have it redirected to a folder > that I never look at. Then if I want to find an email thread I can > search that folder and easily respond from within my normal email > client. > > Is there any downside to CCing LKML?
I think the question becomes, do we want *everything* posted to LKML? For example, based on the last 30 days, the kernel the monthly addition to LKML traffic from my corner of the kernel would be in this ballpark: $ notmuch count date:30d.. to:intel-...@lists.freedesktop.org or to:dri-de...@lists.freedesktop.org and not to linux-ker...@vger.kernel.org and subject:PATCH 96904 OTOH LKML is already a firehose that's impossible to drink from, so not much difference there... BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
