All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dave Chinner <david@fromorbit.com>
Cc: djwong@kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [GIT PULL] xfs: bug fixes for 6.4-rc2
Date: Wed, 10 May 2023 22:12:55 -0500	[thread overview]
Message-ID: <CAHk-=whtWTqXXD29n4z0qni-xM_4OPE-6u3vw_qjkiz05BHVZg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wjJ1veddRdTUs5BfofupuPxMoVHBUbAOmHw6p4pXPq5FQ@mail.gmail.com>

On Wed, May 10, 2023 at 9:49 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That sounds like you will fail all build farms that happen to have
> this compiler version.

Side note: it might have helped if you indicated it was some very
particular old compiler. It's hard to tell. What made me decide to
unpull was really the fact that you seemed so cavalier about it.

The whole "no warnings" thing has been quite important. CONFIG_WERROR
can sometimes be annoying - particularly when a new compiler
introduces a new warning - but it got introduced because I got
*really* tired of people just ignoring warning, and as we had one or
two build warnings, new ones didn't stand out either.

So no, it's *not* ok to say "warnings are harmless". Because they
really really aren't. Unheeded warnings just beget more warnings, and
you end up being warning-blind.

And CONFIG_WERROR is important, because without that, maintainers
won't react to new warnings, because they'll do their random config
testing on farms, and not *look* at the result, they just look at
success/failure reports. I understand why it is like that, but it does
mean that yes, warnings need to actually cause failures.

So then a new warning in one subsystem will fail the build of all the
other subsystems too.

And who knows - maybe the warning came from some odd experimental (or
really old) compiler version that warned about other things too. It
happens. If so, it's fine - to paraphrase (and mangle): "you can make
some compilers happy all of the time, and all compilers happy some of
the time, but you can't make all compilers happy all of the time".

But if you already found the warning before it even hit the main tree,
I suspect it will hit more than a few oddball situations.

            Linus

  reply	other threads:[~2023-05-11  3:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230511015846.GH2651828@dread.disaster.area>
2023-05-11  2:01 ` [GIT PULL] xfs: bug fixes for 6.4-rc2 Dave Chinner
2023-05-11  2:49   ` Linus Torvalds
2023-05-11  3:12     ` Linus Torvalds [this message]
2023-05-11 16:50     ` Darrick J. Wong
2023-05-11 17:47       ` Linus Torvalds
2023-05-11 18:04         ` Linus Torvalds
2023-05-11 18:08         ` Darrick J. Wong
2023-05-12  1:28         ` Dave Chinner
2023-05-11 22:04   ` 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='CAHk-=whtWTqXXD29n4z0qni-xM_4OPE-6u3vw_qjkiz05BHVZg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.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.