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:   Sat, 23 Jan 2021 03:38:41 +0100
From:   Sedat Dilek <sedat.dilek@...il.com>
To:     Dan Carpenter <dan.carpenter@...cle.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 Fri, Jan 22, 2021 at 1:34 PM Dan Carpenter <dan.carpenter@...cle.com> wrote:
>
> 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.
>

Is there an official rule to label patches for Linux-next?

Usually - when I was more active on Linux-next development - folks add
a "PATCH -next" to the subject.
Of course, this needs additionally a hint in the patch/commit message
against which Linux-next release it is applicable.
Linux-next releases are highly dynamic - a patch might be applicable
to one single "-next" release.
Git trees come and go - are resetted to an older version of a Git tree.

As LKML is CCed - think of the hundreds and thousands of patches
coming in daily.
So a more meaningful subject can give a first orientation.
That was my point.

My €0,02.

- Sedat -

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ