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

[Weijie Yuan]

Jonathan Corbet <corbet@xxxxxxx> writes:

> Weijie Yuan <kernel@xxxxxxxxx> 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!