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  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, 23 Jan 2017 08:34:58 -0200
From:   Mauro Carvalho Chehab <>
To:     Joe Perches <>
Cc:     Jonathan Corbet <>,,
Subject: Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks


Em Fri, 13 Jan 2017 12:03:24 -0800
Joe Perches <> escreveu:

> On Fri, 2017-01-13 at 12:41 -0700, Jonathan Corbet wrote:
> > On Tue, 10 Jan 2017 14:09:51 -0800

Sorry to not reply earlier... just returned today from vacations.

> > Joe Perches <> wrote:
> >   
> > > Make these files symlinks to the .rst equivalents  
> > 
> > So I am not necessarily opposed to doing this, but the changelog lacks
> > one important thing: why do we need to make that change?  Have the
> > existing one-liner files been a problem somehow?  
> The files tell people to open other files.
> Giving the old link to people just tells them to
> use the new filename instead.
> symlinks open the new file automatically.
> $ head Documentation/CodingStyle
> This file has moved to process/coding-style.rst
> vs a symlink
> $ head Documentation/CodingStyle
> .. _codingstyle:
> Linux kernel coding style
> =========================
> This is a short document describing the preferred coding style for the
> linux kernel.  Coding style is very personal, and I won't **force** my
> views on anybody, but this is what goes for anything that I have to be
> able to maintain, and I'd prefer it for most other things too.  Please
> at least consider the points made here.

IMHO, we should either use symlinks or files with "replaced by" contents.

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.


Powered by blists - more mailing lists