Hi, On Sat, Sep 21, 2019 at 1:56 AM Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > > On Fri, 20 Sep 2019, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> 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? I swear that I was involved in a conversation in the past where someone suggested to stop CCing LKML on patches and Jonathan Corbet jumped in and said that he supported CCing LKML on all patches. I searched for that conversation and couldn't find it, so it's possible I dreamed it. Maybe he can confirm? > 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-gfx@xxxxxxxxxxxxxxxxxxxxx or to:dri-devel@xxxxxxxxxxxxxxxxxxxxx and not to linux-kernel@xxxxxxxxxxxxxxx and subject:PATCH > 96904 > > OTOH LKML is already a firehose that's impossible to drink from, so not > much difference there... Right. At this point I think LKML is just useful as a dumping ground and not a place to look for patches or conversations without filters. It feels fine to keep using it that way. Having another list (like ksummit-discuss) for conversations with a higher signal-to-noise ratio seems like a fine way forward to me. -Doug
