All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Fengguang Wu <wfg@linux.intel.com>
Cc: Kay Sievers <kay@vrfy.org>, David Miller <davem@davemloft.net>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Reducing the noise level of build error notifications to 0
Date: Sat, 16 Jun 2012 08:27:20 -0700	[thread overview]
Message-ID: <20120616152720.GA7914@kroah.com> (raw)
In-Reply-To: <20120616042010.GA8979@localhost>

On Sat, Jun 16, 2012 at 12:20:10PM +0800, Fengguang Wu wrote:
> > > How about also cc: not only the author where you mention it above, but
> > > everyone who signed-off on the patch?  That would provide a bit of peer
> > > pressure to ensure that the problems get fixed.
> > 
> > That's (interesting and) good point. If me understand you right:
> > 
> > - TO: author, CC: Signed-off-by, CC: (sub-)subsystem mailing list
> >   for build errors
> > 
> > - TO: author, CC: Signed-off-by (but sure, remove the top level busy maintainers)
> >   for gcc warnings

Well, if I sign-off on a patch, I want to know about gcc warnings that
were added by it, don't not email me just because you think I'm busy.

> Or, just remove the committer from CC: and add Reviewed-by to CC: 
> By reviewing, one should already be familiar with the patch.

I don't think you should drop the committer, but maybe that's just me.

> > - TO: author
> >   for sparse warnings (however I'm still too afraid to enable sparse checks)

This might get tougher in some areas of the kernel like the
drivers/staging/ tree where people incrementally fix things up, like fix
trailing space issues on one patch, which doesn't change the rest of the
line that might have had coding style or sparse issues in it.  That's
why I can't always run checkpatch.pl on patches sent to me, and why
sparse might not help out.

But, I'd love to see sparse run on other areas of the kernel (i.e.
anything not in drivers/staging/) hopefully it would get those areas
fixed up properly.

thanks,

greg k-h

  reply	other threads:[~2012-06-16 15:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-16  0:02 [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind' wfg
2012-06-16  1:15 ` Stephen Rothwell
2012-06-16  1:53   ` Fengguang Wu
2012-06-16  1:16 ` Fengguang Wu
2012-06-16  1:47   ` Greg Kroah-Hartman
2012-06-16  2:50     ` Reducing the noise level of build error notifications to 0 Fengguang Wu
2012-06-16  3:44       ` Greg Kroah-Hartman
2012-06-16  4:11         ` Fengguang Wu
2012-06-16  4:20           ` Fengguang Wu
2012-06-16 15:27             ` Greg Kroah-Hartman [this message]
2012-06-17  3:35               ` Fengguang Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120616152720.GA7914@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=davem@davemloft.net \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=wfg@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.