linux-kernel - Re: [PATCH] xfs: Use the correct style for SPDX License Identifier

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:   Mon, 27 Apr 2020 13:46:25 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Nishad Kamdar <nishadkamdar@...il.com>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] xfs: Use the correct style for SPDX License Identifier

On Mon, Apr 27, 2020 at 1:39 PM Joe Perches <joe@...ches.com> wrote:
>
> > The fact is, there *is * a reason to avoid the pedantic "change to new
> > version" - pointless churn.
>
> Have you *looked* at this proposed change?
>
> It just changes // SPDX comments to /* */ in .h files.

That's not what I was reacting to - it was you arguing with Greg about
how we use the legacy format.

I really don't care at all about the comment character choices
(either), but wanted to point out that as far as the kernel is
concerned, the "deprecated" spdx keys simply arent' deprecated, they
are just as valid.

> Piecemeal changes aren't great.

Piecemeal changes are fine, when the change doesn't have to be done AT ALL.

There is simply no point in EVER changing "GPL-2.0" into
"GPL-2.0-only" etc, unless the thing is then touched for some other
reason (which it may never be).

Scripted changes are not as useful as you think. They often cause
unnecessary noise in other respects.

I'm constantly seeing stupid pointless work due to irrelevant patches
that then show up in "get_maintainer" output because they show up as
changes to drivbers that nobody cares about.

Or "git blame -C" things that I have to ignore and go past that
history because the scripted change showed an (uninteresting) change.

The fact is, pointless churn is BAD. It's a real expense. The whole
"get it over with once" argument is simply completely wrong.

There are real advantages to "don't touch stuff that doesn't actively
need touching".

              Linus