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

[Jonathan Corbet <corbet@lwn.net>]

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