linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Justin Stitt <justinstitt@google.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Tom Rix <trix@redhat.com>, Michal Marek <michal.lkml@markovi.net>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	clang-built-linux <llvm@lists.linux.dev>
Subject: Re: [PATCH] Makefile.extrawarn: re-enable -Wformat for clang
Date: Wed, 3 Aug 2022 02:08:39 +0900	[thread overview]
Message-ID: <CAK7LNAQvH=feO_d=0rLGYYQ2YYi=7NRYxGXcYSpYMvqSyOBgew@mail.gmail.com> (raw)
In-Reply-To: <YugYbvRu1xqnx6mC@dev-arch.thelio-3990X>

On Tue, Aug 2, 2022 at 3:16 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Mon, Aug 01, 2022 at 10:40:29AM -0700, Justin Stitt wrote:
> > > OK, I think that will be good timing.
> > > Please ping me if I forget to pick it up.
> > >
> > Hey Masahiro, just pinging to see the state of this PR.
> >
> > I think we are on pace to re-enable this warning.
> >
> > I believe there exists only _two_ patches left still needing to go
> > through along with this patch:
> > 1) https://lore.kernel.org/all/20220718050356.227647-1-hch@lst.de/
>
> This is now in the block tree, so it should be squared away:
>
> https://lore.kernel.org/YuFhR9OoPvM9VsdT@infradead.org/
>
> Stephen is on vacation so -next hasn't updated for a few days but it
> sounds like Mark is going to provide some coverage:
>
> https://lore.kernel.org/YugAzWWl++ArhhPS@sirena.org.uk/
>
> > 2) https://lore.kernel.org/all/YtnDltqEVeJQQkbW@dev-arch.thelio-3990X/
>
> We need to chase this, as I haven't seen an "applied" email. We have two
> options:
>
> 1. Ask the maintainers to apply the change to their branch directly.
> 2. Ask them for an "Ack" so that we can apply that change along with
>    this one.
>
> It is worth a ping asking which they prefer. The first option is
> simpler, as the change that introduced the warning is only in -next so
> it can just be applied to the same branch; the only concern is making
> sure that change makes -rc1. The second option gives us more flexibility
> with enabling the warning in the event that the change missed being
> added to the main pull request but it will require basing the change on
> a non-rc base, which most maintainers don't really like.
>
> It is ultimately up to Masahiro but my vision is:
>
> 1. Ping the patch, asking how to proceed.
> 2. If the maintainers can pick it up and it will make the merge window,
>    let them apply it then apply this patch to the Kbuild tree for -next.
> 3. If they prefer the "Ack" route, wait until mainline contains the
>    problematic patch then apply the warning fix patch and this patch to
>    the Kbuild tree on top of the problematic merge.
> 4. Wait until all other patches are in mainline (I can watch mainline
>    and build it continuously) then pull request the branch containing
>    whatever changes we need.
>
> Masahiro, does that sound reasonable?
>
> Cheers,
> Nathan


Now applied to linux-kbuild.


If my pull request is rejected because of some warnings,
I may end up with dropping this, though.


-- 
Best Regards
Masahiro Yamada

      reply	other threads:[~2022-08-02 17:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 23:23 [PATCH] Makefile.extrawarn: re-enable -Wformat for clang Justin Stitt
2022-07-21 14:27 ` Nick Desaulniers
2022-07-21 14:37   ` Nick Desaulniers
2022-07-21 15:10   ` Nathan Chancellor
2022-07-21 19:37     ` Nathan Chancellor
2022-07-21 20:32       ` Justin Stitt
2022-07-21 21:33       ` Justin Stitt
2022-07-22  4:17     ` Masahiro Yamada
2022-08-01 17:40       ` Justin Stitt
2022-08-01 18:16         ` Nathan Chancellor
2022-08-02 17:08           ` Masahiro Yamada [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='CAK7LNAQvH=feO_d=0rLGYYQ2YYi=7NRYxGXcYSpYMvqSyOBgew@mail.gmail.com' \
    --to=masahiroy@kernel.org \
    --cc=justinstitt@google.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=michal.lkml@markovi.net \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=trix@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).