linux-kernel - Reducing the noise level of build error notifications to 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120616025031.GA8182@localhost>
Date:	Sat, 16 Jun 2012 10:50:31 +0800
From:	Fengguang Wu <wfg@...ux.intel.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Kay Sievers <kay@...y.org>, David Miller <davem@...emloft.net>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Reducing the noise level of build error notifications to 0

[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@...verdev.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/