Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Sep 19, 2019 at 09:22:45AM +0200, Geert Uytterhoeven wrote:
> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
> > > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > > > +at linux-media@xxxxxxxxxxxxxxx as plain text only e-mail. Emails with
> > > > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > > > +to copy the maintainer or sub-maintainer(s).
> > > > >
> > > > > There's too much traffic on mailing lists for me to follow everything, I
> > > > > much prefer being CC'ed on patches.
> > > >
> > > > Well, by using patchwork, the best is to take a look on it at least for
> > > > the patches that you're interested. You could script something using
> > > > pwclient in order to make it easier.
> > > >
> > > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > > patchwork for media patches. What about changing this to:
> > > >
> > > >       Patches for the media subsystem should be sent to the media mailing list
> > > >       at linux-media@xxxxxxxxxxxxxxx as plain text only e-mail. Emails with
> > > >       HTML will be automatically rejected by the mail server. It could be wise
> > > >       to also copy the sub-maintainer(s).
> > >
> > > The documentation should say "Use get_maintainer.pl" and do what it
> > > says.  Everything else is too complicated.
> >
> > +1
> >
> > > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > > wrote the commit from the Fixes tag.  Then I remove Colin King and Kees
> > > Cook from the CC list because they worked all over the tree and I know
> > > them.  I also normally remove LKML if there is another mailing list but
> > > at least one subsystem uses LKML for patchwork so this isn't safe.
> > >
> > > So the safest instructions are "Use get_matainer.pl and add the person
> > > who wrote the commit in the Fixes tag".
> >
> > Better: perhaps get_maintainer.pl can be taught to add the author of the
> > commit pointed to by the Fixes tag, if present?
>
> 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?

-Doug



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux