From: Weijie Yuan <wy@wyuan.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Weijie Yuan <kernel@wyuan.org>, Dongliang Mu <dzm91@hust.edu.cn>,
Alex Shi <alexs@kernel.org>, Yanteng Si <si.yanteng@linux.dev>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: How to attempt to gradually eliminate the compilation output?
Date: Wed, 4 Nov 2026 16:56:12 +0800 [thread overview]
Message-ID: <aurzLOxEnoUWo3Hz@wyuan.org> (raw)
In-Reply-To: <87tslx9ee9.fsf@trenco.lwn.net>
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!
prev parent reply other threads:[~2026-11-04 8:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 6:46 How to attempt to gradually eliminate the compilation output? Weijie Yuan
2026-11-04 7:20 ` Jonathan Corbet
2026-11-04 8:14 ` Weijie Yuan
2026-11-04 8:42 ` Jonathan Corbet
2026-11-04 8:56 ` Weijie Yuan [this message]
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=aurzLOxEnoUWo3Hz@wyuan.org \
--to=wy@wyuan.org \
--cc=alexs@kernel.org \
--cc=corbet@lwn.net \
--cc=dzm91@hust.edu.cn \
--cc=kernel@wyuan.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=si.yanteng@linux.dev \
--cc=skhan@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.