Am 18.10.2016 um 00:43 schrieb Jonathan Corbet <cor...@lwn.net>:
> I've only been able to take a quick look at these - I'm buried fairly deep
> at the moment. A few superficial thoughts.
> On Mon, 17 Oct 2016 14:55:37 -0200
> Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:
>> In my opinion, it would be better to move the converted files to be inside
>> a Sphinx build directory, but Jon seems reluctant to that, so, this series
>> use symlinks, as it is easy to move the files in the future with a very
>> patch, if we decide to do so.
> So I raised this topic in talks at both Kernel Recipes and LinuxCon
> Europe, and nobody threw things at me.
sounds good ;-)
> I have come to suspect that I'm
> worrying a little too much about it; maybe we should go ahead and move
> the documents and see who screams. The work could go into docs-next soon,
> and there would be an opportunity to fix things up if all hell breaks
> loose at the kernel summit.
> Can I make some silly requests?
> - Can we move development-process to something shorter, like just
> "process"? We'll be typing it a lot, and tab completion doesn't work in
> most email clients :)
> - I think we should leave pointers behind in the form of one-line "this
> file has moved" messages. Probably only SubmittingPatches and
> CodingStyle need that treatment, I think.
> - The "user manual" is certainly something that has been on my mind as
> well. We have documentation for completely separate audiences all mixed
> together now, and definitely need to fix that. But rather than "user",
> can we paint that shed "admin-guide" or something like that?
One Silly request of mine:
Is there a chance moving "./Documentation" to something shorter
like "./doc"? Even with "Text completion" (in Emacs ), IMO
"Documentation" is to long.
> Thanks for doing all of this,
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html