[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180413135551.0e6d1b12@lwn.net>
Date: Fri, 13 Apr 2018 13:55:51 -0600
From: Jonathan Corbet <corbet@....net>
To: Mike Rapoport <rppt@...ux.vnet.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Richard Henderson <rth@...ddle.net>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Ralf Baechle <ralf@...ux-mips.org>,
James Hogan <jhogan@...nel.org>,
Michael Ellerman <mpe@...erman.id.au>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
kasan-dev@...glegroups.com, linux-alpha@...r.kernel.org,
linux-ia64@...r.kernel.org, linux-mips@...ux-mips.org,
linuxppc-dev@...ts.ozlabs.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 00/32] docs/vm: convert to ReST format
Sorry for the silence, I'm pedaling as fast as I can, honest...
On Sun, 1 Apr 2018 09:38:58 +0300
Mike Rapoport <rppt@...ux.vnet.ibm.com> wrote:
> My thinking was to start with mechanical RST conversion and then to start
> working on the contents and ordering of the documentation. Some of the
> existing files, e.g. ksm.txt, can be moved as is into the appropriate
> places, others, like transhuge.txt should be at least split into admin/user
> and developer guides.
>
> Another problem with many of the existing mm docs is that they are rather
> developer notes and it wouldn't be really straight forward to assign them
> to a particular topic.
All this sounds good.
> I believe that keeping the mm docs together will give better visibility of
> what (little) mm documentation we have and will make the updates easier.
> The documents that fit well into a certain topic could be linked there. For
> instance:
...but this sounds like just the opposite...?
I've had this conversation with folks in a number of subsystems.
Everybody wants to keep their documentation together in one place - it's
easier for the developers after all. But for the readers I think it's
objectively worse. It perpetuates the mess that Documentation/ is, and
forces readers to go digging through all kinds of inappropriate material
in the hope of finding something that tells them what they need to know.
So I would *really* like to split the documentation by audience, as has
been done for a number of other kernel subsystems (and eventually all, I
hope).
I can go ahead and apply the RST conversion, that seems like a step in
the right direction regardless. But I sure hope we don't really have to
keep it as an unorganized jumble of stuff...
Thanks,
jon
Powered by blists - more mailing lists