On Fri, Jan 22, 2021 at 1:34 PM Dan Carpenter [off-list ref] wrote:

On Thu, Jan 21, 2021 at 05:15:56PM +0100, Sedat Dilek wrote:

quoted

On Thu, Jan 21, 2021 at 5:01 PM Lukas Bulwahn [off-list ref] wrote:

quoted

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@gmail.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 -