How to attempt to gradually eliminate the compilation output?

How to attempt to gradually eliminate the compilation output?

[Weijie Yuan]

On Fri, Aug 21, 2026 at 07:18:56PM +0800, Dongliang Mu wrote:
> On 8/21/26 3:22 PM, Weijie Yuan wrote:
> > On Fri, Aug 21, 2026 at 02:54:59PM +0800, Dongliang Mu wrote:
> > > On 8/21/26 1:13 AM, Weijie Yuan wrote:
> > > > The script says:
> > > > 
> > > > $ tools/docs/checktransupdate.py Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
> > > > [1787244823.341547] Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
> > > > [1787244823.630509] commit 54857c52452a ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign")
> > > > [1787244823.680849] commit 6c5c07bc8589 ("docs: process: maintainer-pgp-guide: update kernel.org docs link")
> > > > [1787244823.730027] commit 273aa250f138 ("Documentation: Improve wording on requirements for a free Nitrokey")
> > > > [1787244823.779408] commit f44a29784f68 ("Documentation: update maintainer-pgp-guide for latest best practices")
> > > > [1787244823.779522] 4 commits needs resolving in total
> > > > 
> > > > So I updated this document in chronological order, created four patches
> > > > based on these four outdated commits to make it easier for you to
> > > > review. Hence, you can freely squash them when applying them.
> > > > 
> > > > Tested with make htmldocs, no warning or error made by these patches.
> > > Hi Weijie,
> > > 
> > > Please make sure you execute "  make cleandocs & make htmldocs". Some
> > > warnings may be ignored by further compilation.
> > Hi!
> > 
> > Thanks for emphasizing this. While I do remember I used "make cleandocs
> > && make htmldocs", and checked among those long lines of red warning
> > output to find anything caused by my commit, I indeed didn't notice this
> > warning appearing at the early stage of the compilation.
> > 
> > It seems that I need to have my eyes checked soon. ;-)
> > 
> > Apologize for my recklessness.
> > 
> > Even so, do we have any way to distinguish these long-standing warnings
> > from the new warnings that appear during compilation? In fact, every
> > time I was worried that I might not have noticed the newly appeared
> > warning. Unfortunately, this time it really happened. (For example,
> > setting a new color? for new warnings?) Do you have a better idea or
> > tips for this?
> 
> My suggestion is to keep the log in each file, and you can easily observe
> the diff. Otherwise, even I can ignore some warnings.
> 
> And many contributors are coming together to fix those warnings. If they are
> done, all new warnings are easily captured. Let us do more contribution to
> help this.

Recently I've sent several patches to fix warnings.  But since I am not
familiar with the actual codes of theirs, I'm not confident enough to
touch some parts, but only the most obvious ones.

Since this is a goal that Jon has spent years for, I'm wondering if it's
possible to periodically send out some email notifications, which will
use the file paths from the compiled output to find the recipients and
kindly ask them to to deal with these annoying outputs? Perhaps we could
use a script to do this.?

Thanks.

Re: How to attempt to gradually eliminate the compilation output?

[Jonathan Corbet]

Weijie Yuan <kernel@wyuan.org> writes:

> Recently I've sent several patches to fix warnings.  But since I am not
> familiar with the actual codes of theirs, I'm not confident enough to
> touch some parts, but only the most obvious ones.
>
> Since this is a goal that Jon has spent years for, I'm wondering if it's
> possible to periodically send out some email notifications, which will
> use the file paths from the compiled output to find the recipients and
> kindly ask them to to deal with these annoying outputs? Perhaps we could
> use a script to do this.?

I think that nagging others to fix warnings is not going to make anybody
happy.  The best we can do in that regard is to try to prevent the
addition of new ones.  Beyond that, it is far better to send a patch
than a request for somebody else to make one.  If nothing else, an
incorrect patch is usually the best way to get somebody else to create a
correct one :)

Thanks,

jon

Re: How to attempt to gradually eliminate the compilation output?

[Weijie Yuan]

Jonathan Corbet <corbet@lwn.net> writes:

> Weijie Yuan <kernel@wyuan.org> writes:
> 
> > Recently I've sent several patches to fix warnings.  But since I am not
> > familiar with the actual codes of theirs, I'm not confident enough to
> > touch some parts, but only the most obvious ones.
> >
> > Since this is a goal that Jon has spent years for, I'm wondering if it's
> > possible to periodically send out some email notifications, which will
> > use the file paths from the compiled output to find the recipients and
> > kindly ask them to to deal with these annoying outputs? Perhaps we could
> > use a script to do this.?
> 
> I think that nagging others to fix warnings is not going to make anybody
> happy.

That's sure and that wasn't what I intended. 

I'd be happy to do the work, but putting myself in their shoes, I worry
they might think, "Someone from nowhere, who isn't familiar with our
development process/workflow, is sending patches and just adding noise.
It would be quicker and easier if they simply pointed out the problems
and let us fix them ourselves."

For example, last week I was about to send a small patch when,
fortunately, I searched lore one more time and found that an equivalent
patch had already been posted to their list, but hadn't been merged yet.

These warnings span many subsystems, and I worry that sending patches
before I understand their respective workflows might come across as a
bit impolite: "We already have this fix in our development tree; you
should have checked first."

> The best we can do in that regard is to try to prevent the
> addition of new ones.

I haven't looked into this in detail yet, but I suspect some new
warnings crop up after each merge window from other subsystems' trees
without our side noticing. So could we be fixing roughly as many
warnings as we gain each cycle? :)

> Beyond that, it is far better to send a patch than a request for
> somebody else to make one.  If nothing else, an incorrect patch is
> usually the best way to get somebody else to create a correct one :)

Ah yes, true. ;-) So please bear with my poor patches then, low-quality
patch is unintentional but inevitable. ;)

Thanks!

Re: How to attempt to gradually eliminate the compilation output?

[Jonathan Corbet]

Weijie Yuan <wy@wyuan.org> writes:

> Jonathan Corbet <corbet@lwn.net> writes:
>
>> Weijie Yuan <kernel@wyuan.org> writes:
>> 
>> > Recently I've sent several patches to fix warnings.  But since I am not
>> > familiar with the actual codes of theirs, I'm not confident enough to
>> > touch some parts, but only the most obvious ones.
>> >
>> > Since this is a goal that Jon has spent years for, I'm wondering if it's
>> > possible to periodically send out some email notifications, which will
>> > use the file paths from the compiled output to find the recipients and
>> > kindly ask them to to deal with these annoying outputs? Perhaps we could
>> > use a script to do this.?
>> 
>> I think that nagging others to fix warnings is not going to make anybody
>> happy.
>
> That's sure and that wasn't what I intended. 
>
> I'd be happy to do the work, but putting myself in their shoes, I worry
> they might think, "Someone from nowhere, who isn't familiar with our
> development process/workflow, is sending patches and just adding noise.
> It would be quicker and easier if they simply pointed out the problems
> and let us fix them ourselves."
>
> For example, last week I was about to send a small patch when,
> fortunately, I searched lore one more time and found that an equivalent
> patch had already been posted to their list, but hadn't been merged yet.
>
> These warnings span many subsystems, and I worry that sending patches
> before I understand their respective workflows might come across as a
> bit impolite: "We already have this fix in our development tree; you
> should have checked first."

Well-intentioned patches are rarely seen as impolite.

It's always worth looking at linux-next before trying to fix something;
if there is a fix in their tree, it should really be there as well.

>> Beyond that, it is far better to send a patch than a request for
>> somebody else to make one.  If nothing else, an incorrect patch is
>> usually the best way to get somebody else to create a correct one :)
>
> Ah yes, true. ;-) So please bear with my poor patches then, low-quality
> patch is unintentional but inevitable. ;)

Thanks for working to make our documentation better!

jon

Re: How to attempt to gradually eliminate the compilation output?

[Weijie Yuan]

Jonathan Corbet <corbet@lwn.net> writes:

> Weijie Yuan <wy@wyuan.org> writes:
> 
> > Jonathan Corbet <corbet@lwn.net> writes:
> >
> >> Weijie Yuan <kernel@wyuan.org> writes:
> >> 
> >> > Recently I've sent several patches to fix warnings.  But since I am not
> >> > familiar with the actual codes of theirs, I'm not confident enough to
> >> > touch some parts, but only the most obvious ones.
> >> >
> >> > Since this is a goal that Jon has spent years for, I'm wondering if it's
> >> > possible to periodically send out some email notifications, which will
> >> > use the file paths from the compiled output to find the recipients and
> >> > kindly ask them to to deal with these annoying outputs? Perhaps we could
> >> > use a script to do this.?
> >> 
> >> I think that nagging others to fix warnings is not going to make anybody
> >> happy.
> >
> > That's sure and that wasn't what I intended. 
> >
> > I'd be happy to do the work, but putting myself in their shoes, I worry
> > they might think, "Someone from nowhere, who isn't familiar with our
> > development process/workflow, is sending patches and just adding noise.
> > It would be quicker and easier if they simply pointed out the problems
> > and let us fix them ourselves."
> >
> > For example, last week I was about to send a small patch when,
> > fortunately, I searched lore one more time and found that an equivalent
> > patch had already been posted to their list, but hadn't been merged yet.
> >
> > These warnings span many subsystems, and I worry that sending patches
> > before I understand their respective workflows might come across as a
> > bit impolite: "We already have this fix in our development tree; you
> > should have checked first."
> 
> Well-intentioned patches are rarely seen as impolite.
> 
> It's always worth looking at linux-next before trying to fix something;
> if there is a fix in their tree, it should really be there as well.

Thanks, learned a lot indeed. It turns out that what I was worried about
already had a solution. Will take a look at linux-next each time later.

Thanks!