From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jiri Kosina <jkosina@suse.cz>,
ksummit-discuss@lists.linux-foundation.org,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Documentation issues
Date: Tue, 27 Jun 2017 07:31:21 -0300 [thread overview]
Message-ID: <20170627073121.784388ad@vento.lan> (raw)
In-Reply-To: <CAKMK7uE+nG==pdEEDsT6or1wWa=izc1UKEyn0V-66hkVwsTmog@mail.gmail.com>
Em Tue, 27 Jun 2017 10:41:27 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> escreveu:
> On Mon, Jun 26, 2017 at 11:28 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, June 26, 2017 07:58:27 AM Takashi Iwai wrote:
> >> On Sun, 25 Jun 2017 22:56:07 +0200,
> >> Jiri Kosina wrote:
> >> >
> >> > On Sat, 24 Jun 2017, Mauro Carvalho Chehab wrote:
> >> >
> >> > > > There are pieces of .txt documentation falling into the "well-knows source of
> >> > > > information" category, with many references to them all over the Web.
> >> > > > kernel-parameters.txt is probably the most spectacular example here, but there
> >> > > > are others.
> >> > > >
> >> > > > Let us not move or rename these, please, or at least put symbolic links in
> >> > > > place to point to the new locations or similar, such that the existing WWW
> >> > > > links pointing to the documentation at kernel.org still work going forward.
> >> > > >
> >> > > > And if we have moved or renamed them already, can we possibly make these
> >> > > > links work again somehow?
> >> > >
> >> > > Agreed. We discussed in the past about two alternatives for those
> >> > > "well known" documents:
> >> > >
> >> > > 1) write a small text on the old file pointing to the
> >> > > new location;
> >> > > 2) use symlink.
> >> > >
> >> > > Right now, we're actually mixing (1) and (2). IMHO, we should either
> >> > > do (1) or (2).
> >> >
> >> > Unfortunately option (3) has also been applied to some of the files:
> >> >
> >> > $ ll Documentation/kernel-parameters.txt
> >> > ls: cannot access 'Documentation/kernel-parameters.txt': No such file or directory
> >> >
> >> > I wasn't sure whether this was intentional or not. But if not, I'll
> >> > happily send a patch that introduces a symlink.
> >>
> >> If we do symlinks, wouldn't it be cleaner to separate the old doc
> >> directory from the new doc directory? That is, Documentation/* keeps
> >> the old txt or symlinks while the ReST is put in another directory,
> >> say, docs/* as originally suggested.
> >
> > That actually sounds like a good idea to me. :-)
> >
> > Question is if it's not too late to do that now that we have all that stuff
> > under Documentation/.
>
> I think it's a bit late, at least from more documentation-active
> susbsystems like gpu/. The docbook->rst switch was pains, dealing once
> more with piles of renames isn't really something I'd like to do. And
> one of the main selling points of .rst was that it integrates much
> more smoothly into our existing pile of .txt docs, whereas the
> DocBook/ subdir was always a bit a ghetto. Forcing another split seems
> ill-advised to me.
Yeah, while I would love that the docs dir would be just docs/, I
also think it is a bit late. Well, renaming patches are actually
handled nice by git (a way nicer than docbook->rst conversion),
and shouldn't hurt that much.
Still, all references by filename will require changes due to the
directory change, both inside the Kernel and on website URLs).
So, we may end needing to have another set of symlinks.
Thanks,
Mauro
next prev parent reply other threads:[~2017-06-27 10:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-23 18:39 Jonathan Corbet
2017-06-23 23:09 ` Rafael J. Wysocki
2017-06-24 12:03 ` Rafael J. Wysocki
2017-06-24 10:46 ` Mauro Carvalho Chehab
2017-06-24 12:20 ` Rafael J. Wysocki
2017-06-24 13:41 ` Mauro Carvalho Chehab
2017-06-25 20:56 ` Jiri Kosina
2017-06-26 1:20 ` Mauro Carvalho Chehab
2017-06-26 21:18 ` Rafael J. Wysocki
2017-06-26 5:58 ` Takashi Iwai
2017-06-26 21:28 ` Rafael J. Wysocki
2017-06-27 8:41 ` Daniel Vetter
2017-06-27 10:31 ` Mauro Carvalho Chehab [this message]
2017-06-26 22:18 ` Jonathan Corbet
2017-06-27 18:42 ` Bird, Timothy
2017-06-28 19:48 ` Geert Uytterhoeven
[not found] ` <CAFhKne8ZttmqWYJToCw9EDywzeMdp=eiFpoZ+O5xrzmKnpA09Q@mail.gmail.com>
[not found] ` <CAFhKne_W-EbjUd_Cm4kyBHrVK6K9r8Ss3gY0ogO1nztbQZYBEg@mail.gmail.com>
2017-06-25 21:32 ` Matthew Wilcox
2017-06-25 21:42 ` Rafael J. Wysocki
2017-06-26 1:15 ` Mauro Carvalho Chehab
2017-06-26 21:16 ` Rafael J. Wysocki
2017-06-26 0:58 ` Mauro Carvalho Chehab
2017-06-25 16:13 ` Jonathan Corbet
2017-06-26 12:19 ` Mark Brown
2017-06-27 8:38 ` Daniel Vetter
2017-06-27 15:33 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170627073121.784388ad@vento.lan \
--to=mchehab@s-opensource.com \
--cc=daniel.vetter@ffwll.ch \
--cc=jkosina@suse.cz \
--cc=ksummit-discuss@lists.linux-foundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox