Reducing the noise level of build error notifications to 0

Fengguang Wu
2012-06-16T02:50:38Z

[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