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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 16 Jun 2012 08:27:20 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Fengguang Wu <wfg@...ux.intel.com>
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: Re: Reducing the noise level of build error notifications to 0

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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ