All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL v2] MFD for v5.9
Date: Mon, 17 Aug 2020 09:14:31 +0100	[thread overview]
Message-ID: <20200817081431.GQ4354@dell> (raw)
In-Reply-To: <CAHk-=whSXfOKSXeaSBP9MtgtYewZ_xpnAnTj96_4wKLndpzMjA@mail.gmail.com>

On Sat, 15 Aug 2020, Linus Torvalds wrote:

> On Fri, Aug 14, 2020 at 7:42 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > Here is the new pull request.  It has been tested; locally, by
> > TuxBuild and the Intel 'kernel test robot' [0].  Please consider this for
> > addition into v5.9.  All of these patches have also soak tested in
> > -next for a considerable amount of time.
> 
> I'm extremely annoyed by this all, but I've pulled this.
> 
> Please just *STOP* doing any W=1 fixes (and most definitely W=2 ones -
> many of those warnings are just plain garbage and indicate more about
> the compiler than they do about the code) if you can't then make damn
> sure that the warnings that actually matter are always *ALWAY* taken
> care of.
> 
> I absolutely abhor warnings in the default build, just because they
> only result in people ignoring them. Which is exactly what happened
> bvecause you then tried to care about the more-or-less worthless W=1
> ones.
> 
> So a clean build is really important to me. And developers who don't
> check and follow up on warnings in the normal build are something that
> pisses me off no end.
> 
> Now something like 25 commits are pointlessly rebased just because you
> didn't check warnings properly.

Your point is clear.

Allowing a W=0 warning into my pull-request was a genuine mistake
(most of us are only human after all).  It will be treated as a
learning point, safeguards will be put into place at my end and this
situation should not be repeated in the future.

I shall continue with my W=1 push (not going to touch W=2s however).
It's understandable that to you W=0s are paramount, but as long as
none are introduced then fixing up W=1s can only help to improve the
code-base (not withstanding 'type-limits' of course!) and ensure it's
more in sync/aligned with itself [thinking API documentation warnings
here]).

Thanks for pulling though.  It is appreciated.

Apologies again for the fuss.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2020-08-17  8:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11  7:46 MFD for v5.9 Lee Jones
2020-08-12  6:39 ` [GIT PULL] " Lee Jones
2020-08-12 19:05 ` Linus Torvalds
2020-08-13  7:19   ` Lee Jones
2020-08-14 14:42     ` [GIT PULL v2] " Lee Jones
2020-08-15 15:16       ` Linus Torvalds
2020-08-17  8:14         ` Lee Jones [this message]
2020-08-15 15:23       ` pr-tracker-bot

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=20200817081431.GQ4354@dell \
    --to=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.