Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3805591yba; Tue, 23 Apr 2019 09:55:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqxeduiG63v4KIzwPno39yw6Qp23s8Onom1fMBYwmzWuCekbojnRKPi4AHRjgVBfrfRsLbgH X-Received: by 2002:a17:902:4c:: with SMTP id 70mr26365515pla.328.1556038529154; Tue, 23 Apr 2019 09:55:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556038529; cv=none; d=google.com; s=arc-20160816; b=Ulg5iKGSEdOA5rK8bFT4ta7TB+V7+F+h98yolIT/b6t07Uw1npSRl6H2mwnCusazXQ 5YcqiZW+H//Uacq7rJ4pRYmI9lMq46SMmlWrqgx9D5/VPG3UGswtw+2kRtBxrTUu17jj 5cy/7Og9Et4uh6zK5CGzmIp1m7xqtdOz7JOIEFPe1tbL6BIM+Euum2N3yJNYGjQdI5o6 R8VEm2lB/En7pTwrCP6O53ZbOCRHaIor4zjiYl/3OxJHUleHQ/Xq5CfObqn1wpg2ZkM7 32yyPKjo/JWjYW3IHV+UrJKgLq3HLbLgw00WntgR3TwUO5s8+CKvGAHy2wo1b8TmGkDE SKQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=NttYCAfYchxiIiOvmhfI1VPcienjQXCymgz4dO3oGlQ=; b=Y9z8DvixLfBd91e4CJY0bmwKSQS9AzgZP0o/1+X09guRu6WUy8BVYY+NJegwY0C42V xtGR4ppKh44dVguOyVfR8gt5hxr0WFYMLRY2FALxOk2QlLtnAeoFuumk0M0PcXTPRVAn F8vqTkiqBq8k+37NUVjyZx9Xn9spt4Ad28t9AsQ8qiBKVB0LjbQAcqSYWIfL3AZLaaG/ 4Z5eronqfAjt15jrN2QUkTmziZqcXMFiekzYZGJ9OFaMymlhwOf5T5NAufRZLVrPiWjm 00VXttr5D8ZHThJbwLSxCn2K/tf+f5U2489O1jWXGdWYwrw2VEIGQwnEgnE+mG+1uL/z X0+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n11si14125872pgp.482.2019.04.23.09.55.13; Tue, 23 Apr 2019 09:55:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728937AbfDWQyX (ORCPT + 99 others); Tue, 23 Apr 2019 12:54:23 -0400 Received: from ms.lwn.net ([45.79.88.28]:48464 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727831AbfDWQyW (ORCPT ); Tue, 23 Apr 2019 12:54:22 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 770D65A0; Tue, 23 Apr 2019 16:54:20 +0000 (UTC) Date: Tue, 23 Apr 2019 10:54:15 -0600 From: Jonathan Corbet To: David Howells Cc: Mike Snitzer , Peter Zijlstra , Mauro Carvalho Chehab , Linux Doc Mailing List , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst Message-ID: <20190423105415.3a69a0cb@lwn.net> In-Reply-To: <20704.1556031146@warthog.procyon.org.uk> References: <20190423132100.GB7132@redhat.com> <20190423083135.GA11158@hirez.programming.kicks-ass.net> <20190423125519.GA7104@redhat.com> <20190423130132.GT4038@hirez.programming.kicks-ass.net> <20704.1556031146@warthog.procyon.org.uk> Organization: LWN.net X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Apr 2019 15:52:26 +0100 David Howells wrote: > There've been some changes that I've particularly objected to, such as > removing contents lists from files and replacing them with markup like: > > .. contents:: :local: > > This actually impedes use of the file. It should not be necessary to build > the docs to get that for ordinary use. Usability of the text files versus that of the built docs is occasionally something that has to be traded off. As a general rule, I want the text files to remain useful on their own. There is a lot of value in the built docs for a lot of people, but that should not be the only, or even the primary, form of access Tables of contents are certainly a place where that tradeoff makes itself felt. Doing them by hand ensures that they are always present, but requires that people editing the docs also maintain the TOCS - something that experience has shown tends not to happen. That's more of a pain than a little bit of markup, and people don't do it. An automatically generated TOC, instead, is always correct and is linkable. Few people complain about the biggest impediment to the readability of text files, though: the use of kerneldoc comments. That splits the information between the text file and multiple random-seeming locations among tends of thousands of source files. Sometimes the solution here is to move all of the documentation into the source, but that tends to fragment it and make it harder to find; it's certainly not the right place for many kinds of docs. In general, it's hard to create a coherent story that way. Suggestions / patches on how to improve things for *all* users of the docs are certainly welcome! I am, incidentally, toying with the idea of trying to put together a documentation microconf at the Linux Plumbers Conference this year. If anybody out there thinks that's a good idea and would like to participate, please let me know. > Anyway, the biggest doc issue in the kernel isn't addressed by the conversion > to ReST: and that is that most people don't seem interested in documenting > stuff - whether because writing documentation isn't as fun as writing code or > the fact that English isn't their native language, I don't know. I can > sympathise more with the latter. I believe there's enough experience now to say that using RST increases contributions to the documentation. Just having something that approaches a coherent approach to docs (though we are a *long* way from that still) makes the whole thing more accessible. It doesn't solve our documentation issues by any stretch, but it helps. Thanks, jon