Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1587330
| From | Daniel Vetter <daniel@ffwll.ch> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks |
| Date | 2017-02-24 09:00 +0100 |
| Message-ID | <teiXf-5sB-1@gated-at.bofh.it> (permalink) |
| References | <sYcVP-70a-5@gated-at.bofh.it> <sZg1k-4RX-21@gated-at.bofh.it> <sZgkG-5dS-25@gated-at.bofh.it> <t2Kcy-5gI-11@gated-at.bofh.it> <taSZk-75C-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
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
csiph-web