Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Mauro Carvalho Chehab <mchehab@s-opensource.com>]

Hi,

Em Fri, 13 Jan 2017 12:03:24 -0800
Joe Perches <joe@perches.com> 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 <joe@perches.com> 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.

Thanks,
Mauro