lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 22 Jan 2021 15:33:54 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Sedat Dilek <sedat.dilek@...il.com>
Cc:     Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        linux-kbuild@...r.kernel.org,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Clang-Built-Linux ML <clang-built-linux@...glegroups.com>,
        Joe Perches <joe@...ches.com>,
        Ralf Ramsauer <ralf.ramsauer@...-regensburg.de>,
        Pia Eichinger <pia.eichinger@...oth-regensburg.de>,
        kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: adjust to clang-version.sh removal

On Thu, Jan 21, 2021 at 05:15:56PM +0100, Sedat Dilek wrote:
> On Thu, Jan 21, 2021 at 5:01 PM Lukas Bulwahn <lukas.bulwahn@...il.com> wrote:
> >
> > Commit 6c8ad4427f6e ("kbuild: check the minimum compiler version in
> > Kconfig") removed ./scripts/clang-version.sh and moved its content to
> > ./scripts/cc-version.sh.
> >
> > Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
> >
> >   warning: no file matches    F:    scripts/clang-version.sh
> >
> > The CLANG/LLVM BUILD SUPPORT section in MAINTAINERS intends to track
> > changes in ./scripts/clang-version.sh; as the file is removed, track
> > changes in ./scripts/cc-version.sh instead now.
> >
> > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@...il.com>
> 
> Good catch, Lukas.
> 
> As a tipp:
> Next time you can pass '--subject-prefix="PATCH next-YYYYMMDD"' when
> doing 'git format-patch ...' (or whatever you use to generate the
> patch).

I've never seen anyone use this prefix before.

What does the date really help?  In staging, we apply everything on top
of staging-next and if it doesn't apply then we don't investigate, we
just say "doesn't apply.  resend if needed".

We may as well just say [PATCH linux-next].  No one is ever going to
look up the date if it doesn't apply to the latest linux-next.

regards,
dan carpenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ