lkml.org 
[lkml]   [2017]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks
Hi Mauro,

On Mon, Jan 23, 2017 at 11:34 AM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
> 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
>> > 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.

Agreed, about temporary vs. permanent.

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

When will/can we get rid of them?
Old (doh) kernels, and new versions of stable kernels will keep on having
them for the next +10 years.

To me, these[*] filenames are more like a user-visible API, which should
not be changed without given consideration.

[*] CodingStyle and SubmittingPatches (there may be others) are linked from
many web pages and email archives.
Anyone looked at how many links Google thinks there are?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

\
 
 \ /
  Last update: 2017-01-23 11:45    [W:0.083 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site