linux-nvdimm.lists.01.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Bart Van Assche <bvanassche@acm.org>,
	ksummit-discuss@lists.linuxfoundation.org,
	linux-nvdimm@lists.01.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Matthew Wilcox <willy6545@gmail.com>,
	linux-kernel@vger.kernel.org,
	Steve French <stfrench@microsoft.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	"Tobin C. Harding" <me@tobin.cc>
Subject: Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
Date: Fri, 13 Sep 2019 07:59:11 -0700	[thread overview]
Message-ID: <20190913145911.GA21121@roeck-us.net> (raw)
In-Reply-To: <20190913105446.2b7af558@coco.lan>

On Fri, Sep 13, 2019 at 10:54:46AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 13 Sep 2019 08:56:30 -0400
> Matthew Wilcox <willy6545@gmail.com> escreveu:
> 
> > It's easy enough to move the kernel-doc warnings out from under W=1. I only
> > out them there to avoid overwhelming us with new warnings. If they're
> > mostly fixed now, let's make checking them the default.
> 
> Didn't try doing it kernelwide, but for media we do use W=1 by default,
> on our CI instance.
> 

I used to do that as well, but gave up on it since it resulted in lots
of warnings from generic kernel include files. I have not tried recently,
so maybe that is no longer the case.

> There's a few warnings at EDAC, but they all seem easy enough to be
> fixed.
> 

Acceptance depends on the maintainer, really. I had patches rejected
when trying to fix W=1 warnings, so I no longer do it.

> So, from my side, I'm all to make W=1 default.
> 
Seems to me that would require a common agreement that maintainers
are expected to accept fixes for problems reported with W=1.

Guenter

> Regards,
> Mauro
> 
> > 
> > On Thu., Sep. 12, 2019, 16:01 Bart Van Assche, <bvanassche@acm.org> wrote:
> > 
> > > On 9/12/19 8:34 AM, Joe Perches wrote:  
> > > > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:  
> > > >> On 9/11/19 5:40 PM, Martin K. Petersen wrote:  
> > > >>> * The patch must compile without warnings (make C=1  
> > > CF="-D__CHECK_ENDIAN__")  
> > > >>>   and does not incur any zeroday test robot complaints.  
> > > >>
> > > >> How about adding W=1 to that make command?  
> > > >
> > > > That's rather too compiler version dependent and new
> > > > warnings frequently get introduced by new compiler versions.  
> > >
> > > I've never observed this myself. If a new compiler warning is added to
> > > gcc and if it produces warnings that are not useful for kernel code
> > > usually Linus or someone else is quick to suppress that warning.
> > >
> > > Another argument in favor of W=1 is that the formatting of kernel-doc
> > > headers is checked only if W=1 is passed to make.
> > >
> > > Bart.
> > >
> > > _______________________________________________
> > > Ksummit-discuss mailing list
> > > Ksummit-discuss@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> > >  
> 
> 
> 
> Thanks,
> Mauro
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

  reply	other threads:[~2019-09-13 14:59 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-11 15:48 [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
2019-09-11 15:48 ` [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams
2019-09-13 15:37   ` [Ksummit-discuss] " Mauro Carvalho Chehab
2019-09-11 15:48 ` [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
2019-09-11 17:34   ` [Ksummit-discuss] " Verma, Vishal L
2019-09-16 12:35   ` Jani Nikula
2019-10-01 13:55   ` Jonathan Corbet
2019-10-01 18:17     ` Martin K. Petersen
2019-11-07 20:13     ` Jonathan Corbet
2019-11-08  2:41       ` Dan Williams
2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
2019-09-11 17:42   ` [Ksummit-discuss] " Vishal Verma
2019-09-11 17:45   ` Dave Jiang
2019-09-11 18:43   ` [Ksummit-discuss] " Dan Carpenter
2019-09-11 22:11     ` Jens Axboe
2019-09-12  7:41       ` Dan Williams
2019-09-12  8:24         ` Miguel Ojeda
2019-09-12 10:18           ` Joe Perches
2019-09-12 11:02             ` Joe Perches
2019-09-12 14:17               ` Dan Williams
2019-09-12 14:51                 ` Joe Perches
2019-09-12 14:42             ` Miguel Ojeda
2019-09-13  7:09       ` Jonathan Corbet
2019-09-13 11:48         ` Dan Carpenter
2019-09-13 12:18           ` Dan Williams
2019-09-13 15:00           ` Randy Dunlap
2019-09-13 15:46             ` Rob Herring
2019-09-13 16:42               ` Joe Perches
2019-09-13 19:32                 ` Rob Herring
2019-09-13 17:57             ` Geert Uytterhoeven
2019-09-16 12:42           ` Jani Nikula
     [not found]           ` <20190917161608.GA12866@ziepe.ca>
2019-09-17 21:59             ` Dan Williams
2019-09-13 21:44       ` Martin K. Petersen
2019-09-16  7:01         ` Dan Carpenter
2019-09-16 17:08           ` Martin K. Petersen
2019-09-13  2:11     ` Aneesh Kumar K.V
2019-09-13  5:00       ` Greg KH
2019-09-11 20:30   ` Joe Perches
2019-09-11 16:40 ` [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen
2019-09-12 13:31   ` [Ksummit-discuss] " Bart Van Assche
2019-09-12 15:34     ` Joe Perches
2019-09-12 20:01       ` Bart Van Assche
2019-09-12 20:34         ` Joe Perches
2019-09-13 14:26           ` Rob Herring
2019-09-13 18:42             ` Joe Perches
2019-09-13 19:17               ` Mauro Carvalho Chehab
2019-09-13 20:33                 ` Joe Perches
2019-09-13 12:56         ` Matthew Wilcox
2019-09-13 13:54           ` Mauro Carvalho Chehab
2019-09-13 14:59             ` Guenter Roeck [this message]
2019-09-13 22:03     ` Martin K. Petersen
2020-04-29 13:55       ` Roman Bolshakov
2019-09-12 13:10 ` Bart Van Assche

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=20190913145911.GA21121@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=bvanassche@acm.org \
    --cc=dvyukov@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mchehab@kernel.org \
    --cc=me@tobin.cc \
    --cc=stfrench@microsoft.com \
    --cc=willy6545@gmail.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;
as well as URLs for NNTP newsgroup(s).