public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Reducing the noise level of build error notifications to 0
Date: Sat, 16 Jun 2012 10:50:31 +0800	[thread overview]
Message-ID: <20120616025031.GA8182@localhost> (raw)
In-Reply-To: <20120616014732.GA2981@kroah.com>

[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.

> > 2) only notify the mailing list directly associated with the git tree.
> >    In this particular case, to only CC devel@driverdev.osuosl.org, and
> >    to avoid the linux-mtd and linuxppc-dev lists.
> 
> Yes, that would be the best thing to do to start with, then let the
> developers take it from there.

Good point!  The developers knows best who to CC :)

Thanks,
Fengguang

       reply	other threads:[~2012-06-16  2:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4fdbcd2f.Ta8kRp58FRzqrqaL%wfg@linux.intel.com>
     [not found] ` <20120616011646.GA7847@localhost>
     [not found]   ` <20120616014732.GA2981@kroah.com>
2012-06-16  2:50     ` Fengguang Wu [this message]
2012-06-16  3:44       ` Reducing the noise level of build error notifications to 0 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
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=20120616025031.GA8182@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox