Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934812AbcJQWny (ORCPT ); Mon, 17 Oct 2016 18:43:54 -0400 Received: from tex.lwn.net ([70.33.254.29]:48127 "EHLO vena.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933931AbcJQWno (ORCPT ); Mon, 17 Oct 2016 18:43:44 -0400 Date: Mon, 17 Oct 2016 16:43:42 -0600 From: Jonathan Corbet To: Mauro Carvalho Chehab Cc: Linux Doc Mailing List , Mauro Carvalho Chehab , LKML Subject: Re: [PATCH 00/32] Create an User's manual and improve development-process book Message-ID: <20161017164342.28d4f0c3@lwn.net> In-Reply-To: References: Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1567 Lines: 36 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 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 simple > 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. 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? Thanks for doing all of this, jon