Re: [Ksummit-discuss] [media-submaintainers] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Mark,

On Wed, Jun 19, 2019 at 04:56:02PM +0100, Mark Brown wrote:
> On Wed, Jun 19, 2019 at 05:48:08PM +0300, Laurent Pinchart wrote:
> > On Wed, Jun 19, 2019 at 11:39:02AM -0300, Mauro Carvalho Chehab wrote:
> 
> > > Specially on drivers that build with COMPILE_TEST[1], depending on the 
> > > architecture they're built, false-positive warnings rise, specially
> > > on unusual architecture with has different defines for some 
> > > arch-specific typedefs (signed/unsigned, different integer type,
> > > usage or not of volatile, a different address space, etc).
> 
> > All my kernel compilation scripts use -Werror, and that does a great job
> > at catching problems. It can be a bit annoying at times when someone
> > introduces a warning, but usually a fix will already be posted when I
> > notice my build breaks. The more we use -Werror globally, the faster
> > those new warnings will be caught.
> 
> -Werror is a bit user hostile, it can be incredibly irritating when
> you're debugging things to get things like unused variable warnings from
> your debug code or to be working with an unusual config/arch that throws
> up warnings that aren't normally seen.  A clean build doesn't require us
> to enable -Werror, it requires us to pay attention to warnings.

I agree about the latter. Regarding debugging code I found it was just a
matter of getting used to it and avoiding generating warnings, even in
debug code. -Werror saved me from not noticing warnings introduced by my
code, and with it a git rebase -x compile test stops when I made a
mistake, which is really valuable. I'm not saying it should be enabled
through the whole kernel all of a sudden, but if we can slowly expand
its usage I think we'll end up with better code in the end.

-- 
Regards,

Laurent Pinchart