linux-kernel - Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

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:   Tue, 14 Feb 2017 14:34:38 -0700
From:   Jonathan Corbet <corbet@....net>
To:     Mauro Carvalho Chehab <mchehab@...pensource.com>
Cc:     Joe Perches <joe@...ches.com>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

On Mon, 23 Jan 2017 08:34:58 -0200
Mauro Carvalho Chehab <mchehab@...pensource.com> wrote:

> The main difference between a "pointer file" and a symlink is that the
> first indicates a temporary solution, teaching people that the
> file got renamed and were it is located now. As such, we can remove
> those "pointer files" on some future Kernel releases without much concern.
> 
> A symlink indicates a more permanent situation, as people will keep
> using the symlinked files as before. That means that any attempt to
> remove those in the future will generate concerns.
> 
> So, I'm in favor of using the "pointer files" instead, as it
> gives us an easier way to get rid of them when we find convenient.

So you've all long since forgotten this discussion, I'm sure, but I've
been pondering it on and off for quite a while.

The movement of some of the more well-known documents has been a concern
of mine from the beginning; that is why I delayed those changes for
a cycle and raised the issue at a number of conferences, culminating in
the kernel summit in November.  I got a strong sense of consensus that we
should go ahead and move the files.

As Mauro says, symlinks are forever; they say we'll never really succeed
in rationalizing the structure of Documentation/.  But we don't nail down
the location of any other files in the kernel source tree in this manner,
and my own feeling is that we shouldn't do that here either.  The kernel
source tree is not an API.  So my thinking at the moment is that we should
retain the current "pointer files" in the vague hope that, someday, we
won't need them anymore.

Thanks,

jon