mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Carlos Bilbao <carlos.bilbao@amd.com>
To: Matthew Wilcox <willy@infradead.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Avadhut Naik <Avadhut.Naik@amd.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [RFC] Proposal to relax warnings of htmldocs
Date: Tue, 15 Aug 2023 13:48:45 -0500	[thread overview]
Message-ID: <bc03e31e-8765-143b-9b1b-33ce0768e3ad@amd.com> (raw)
In-Reply-To: <ZNvGz4v2QYowrhk0@casper.infradead.org>

On 8/15/23 13:41, Matthew Wilcox wrote:
> On Tue, Aug 15, 2023 at 08:35:40PM +0200, Miguel Ojeda wrote:
>> On Tue, Aug 15, 2023 at 8:23 PM Jonathan Corbet <corbet@lwn.net> wrote:
>>>
>>> As an alternative, of course, we could consider turning off those
>>> specific warnings entirely for normal builds.
>>
>> It could be nice to get to enforce warning-free builds as soon as possible.
>>
>> Perhaps we could move those to a `W=1`-like group and clean them over
>> time instead? Or do we have that already?
> 
> I think the problem is that we don't run kernel-doc by default.  Instead,
> it's only run for W=1 (and higher) builds.  That's why Carlos doesn't
> see the problems he is introducing in his own builds.  Of course, if
> AMD required building with W=1 then they'd see these problems earlier
> in their own testing.  Apparently they don't.

AMD's testing practices or standards are orthogonal to this discussion. My
contributions to the Documentation effort are entirely voluntary and
independent of my role at AMD.

> 
> Is it time to just run kernel-doc by default?  There aren't _that_
> many kernel-doc warnings now.  Not compared to how they used to be.
> And enabling them for everyone means that new ones won't sneak in.
> I haven't timed how much extra time kernel-doc adds to a build.
> Perhaps that's infeasible.

Thanks,
Carlos

  reply	other threads:[~2023-08-15 18:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15 18:15 Carlos Bilbao
2023-08-15 18:23 ` Jonathan Corbet
2023-08-15 18:35   ` Miguel Ojeda
2023-08-15 18:41     ` Matthew Wilcox
2023-08-15 18:48       ` Carlos Bilbao [this message]
2023-08-16 11:01       ` Jani Nikula
2023-08-16 15:12         ` Carlos Bilbao
2023-08-16 15:15           ` Matthew Wilcox
2023-08-16 15:21             ` Carlos Bilbao
2023-08-16 15:57               ` Matthew Wilcox
2023-08-16 16:47                 ` Carlos Bilbao
2023-08-16 14:54   ` Carlos Bilbao
2023-08-16 15:04     ` Jonathan Corbet

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=bc03e31e-8765-143b-9b1b-33ce0768e3ad@amd.com \
    --to=carlos.bilbao@amd.com \
    --cc=Avadhut.Naik@amd.com \
    --cc=akiyks@gmail.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=willy@infradead.org \
    /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

all inboxes | Powered by JetHome®