Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1580882 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks Jonathan Corbet <corbet@lwn.net> - 2017-02-14 22:40 +0100
    Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks Joe Perches <joe@perches.com> - 2017-02-14 22:40 +0100
    Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks Daniel Vetter <daniel@ffwll.ch> - 2017-02-24 09:00 +0100

#1580882 — Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

On Mon, 23 Jan 2017 08:34:58 -0200
Mauro Carvalho Chehab <mchehab@s-opensource.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

[toc] | [next] | [standalone]

#1580887

(adding Greg KH as I doubt he ever saw the original)

On Tue, 2017-02-14 at 14:34 -0700, Jonathan Corbet wrote:
> On Mon, 23 Jan 2017 08:34:58 -0200
> Mauro Carvalho Chehab <mchehab@s-opensource.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.

I'm still of the opposite opinion.

[toc] | [prev] | [next] | [standalone]

#1587330

On Tue, Feb 14, 2017 at 02:34:38PM -0700, Jonathan Corbet wrote:
> On Mon, 23 Jan 2017 08:34:58 -0200
> Mauro Carvalho Chehab <mchehab@s-opensource.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.

It's a tricky balance, but I think your stance is reasonable and seems to
reflect overall consensus (which might chance, we'll see).

+1 from my side.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web