From: Fengguang Wu <wfg@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 12:20:10 +0800 [thread overview]
Message-ID: <20120616042010.GA8979@localhost> (raw)
In-Reply-To: <20120616041144.GA8666@localhost>
On Sat, Jun 16, 2012 at 12:11:44PM +0800, Fengguang Wu wrote:
> Hi Greg,
>
> On Fri, Jun 15, 2012 at 08:44:20PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Jun 16, 2012 at 10:50:31AM +0800, Fengguang Wu wrote:
> > > [switch to LKML]
> > >
> > > On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> > > > On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > > > > Hi list,
> > > > >
> > > > > I'm sorry if this pile of build errors disturbed you too much. If
> > > > > the error notification is too permissive, I can limit it in two ways:
> > > > >
> > > > > 1) only notify build errors on the first kconfig. There may be a few
> > > > > new error messages show up in the other kconfig builds, however
> > > > > mostly are just irritating duplications.
> > > >
> > > > Duplicates should be suppressed, they are just annoying.
> > >
> > > OK! I'll suppress noises in four ways:
> > >
> > > rule 1: all newly shown-up error messages will be only notified for
> > > the current commit and remembered to be "known bug" thereafter.
> > >
> > > rule 2: when one bad commit triggers build errors in multiple kconfigs,
> > > only one of them will be CCed. The patch author will still get
> > > full information in private emails.
> > >
> > > rule 3: when one bad commit triggers build errors in the _subsequent_
> > > innocent commits of the same branch, the emails will be sent
> > > to myself for manual check first. This will inevitably lead to
> > > more delays (esp. when I'm sleeping), however 2+ bad commits
> > > should not happen frequently.
> > >
> > > rule 4: gcc/sparse warnings will never be CCed. Only private email
> > > notifications will be sent to the author.
> > >
> > > The above rules should be able to reduce the noise level close to 0
> > > for maintainers and public mailing lists.
> > >
> > > The commit author may still see some noises, however the good thing
> > > is, he should be able to tell signals from noises much easier than
> > > the others.
> >
> > 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
Or, just remove the committer from CC: and add Reviewed-by to CC:
By reviewing, one should already be familiar with the patch.
Thanks,
Fengguang
> - TO: author
> for sparse warnings (however I'm still too afraid to enable sparse checks)
>
> > Oh, and thanks for working on this, it's much appreciated.
>
> Thank you :)
>
> Regards,
> Fengguang
next prev parent reply other threads:[~2012-06-16 4:20 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 [this message]
2012-06-16 15:27 ` Greg Kroah-Hartman
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=20120616042010.GA8979@localhost \
--to=wfg@linux.intel.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=kay@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.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.