Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932328AbcK1Iot (ORCPT ); Mon, 28 Nov 2016 03:44:49 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35828 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932105AbcK1Iol (ORCPT ); Mon, 28 Nov 2016 03:44:41 -0500 Date: Mon, 28 Nov 2016 09:44:42 +0100 From: Daniel Vetter To: Peter Zijlstra Cc: Jonathan Corbet , Silvio Fricke , linux-doc@vger.kernel.org, Ming Lei , "Luis R . Rodriguez" , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Jani Nikula Subject: Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup Message-ID: <20161128084442.uqfcar5qx2b7u34v@phenom.ffwll.local> Mail-Followup-To: Peter Zijlstra , Jonathan Corbet , Silvio Fricke , linux-doc@vger.kernel.org, Ming Lei , "Luis R . Rodriguez" , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Jani Nikula References: <20161125215814.GA3061@worktop.programming.kicks-ass.net> <20161127165914.5b84cc65@lwn.net> <20161128072626.GT3092@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161128072626.GT3092@twins.programming.kicks-ass.net> X-Operating-System: Linux phenom 4.8.0-1-amd64 User-Agent: NeoMutt/20161104 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3013 Lines: 65 On Mon, Nov 28, 2016 at 08:26:26AM +0100, Peter Zijlstra wrote: > On Sun, Nov 27, 2016 at 04:59:14PM -0700, Jonathan Corbet wrote: > > On Fri, 25 Nov 2016 22:58:14 +0100 > > Peter Zijlstra wrote: > > > > > Not a fan of this. The atomic_ops.txt file needs a lot of love, and I > > > wouldn't want to edit a .rst file. > > > > > > Then again, I probably won't actually get around to fixing this document > > > any time soon either. > > > > > > But if and when I would get around to it, I'll have to change it back to > > > a regular .txt file. I definitely don't want to make rst/sphinx a pain for anyone, so very much welcome your feedback. > > Peter, could you please describe what the trouble with RST is? > > Mostly that its not txt. I don't know what RST is, and I frankly don't > care. For me changing this is 'make work', and I really don't need that. > > Changing this away from txt will simply make want to write documentation > less, because it means having to figure out wtf RST is first, which > means I'll simply won't do it. I don't think you have to care at all. We've converted thousands of pages of entirely free-form .txt to .rst, and sphinx/rst happily parsed it all. There's the occasional warning, and 0day will report them. But if you don't want to care, then you can choose not to care at all here. The checkpatch/warning police is already picking up on these, so they will get fixed. And if that's too much, then you can also ignore those. > > Most of > > the files in Documentation/ are already almost in RST format; should we > > change them to something else? :) > > Why change them? What was wrong with txt to begin with? In my opinion good docs matter, and one of the key things is to be able to cross reference stuff. And I'd really like to be able to cross-reference to all the core kernel stuff (locks, atomics, workers, timers, all of these) from my driver/subsystem docs. This isn't something you or I ever really will use, but in my experience it is rather useful for people newly reading into a subsystem. And getting new folks on board (at least in subsystems like DRM where we're chronically understaffed for everything) matters. Given that I hope the change in file-ending from .txt to .rst is ok with you, and it won't stop you from updating the docs. If not that'd be bad, since imo anything that makes it harder to type good docs is bad. Another concern some core kernel folks raised is that the .rst markup was too heavy-handed, and makes the text much harder to read. Christoph called it "cat spew". That can be fixed with a much lighter-handed conversion (and 2nd patch iteration was acceptable for Christoph). In this patch the biggest part seems to be the indent shift on the code snippets, and it'd be good to keep those to tell sphinx to fixed-width layout them. But a lot of the other stuff really doesn't need to be if it bothers you. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch