lkml.org 
[lkml]   [2016]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 00/10] Documentation/Sphinx
From
On Tue, May 31, 2016 at 9:27 AM, Markus Heiser
<markus.heiser@darmarit.de> wrote:
>>>> I find it totally unacceptable to require explicitly marking kernel-doc
>>>> comments or source files as being reStructuredText.
>>>> Note that it's all opt-in already. If you add a .rst file that includes
>>>> kernel-doc via the kernel-doc extension, you better make sure the
>>>> comments parse as reStructuredText and render nicely. I'm willing to do
>>>> much of the job for all the things that I care about.
>>>
>>> We have a different POV ... I try to build up a documentation project,
>>> which could use all given kernel-doc markups without any change, where
>>> reST is an "addition". Your approach is to fix kernel-doc comments
>>> if they are referred by a kernl-doc directive in a .rst document.
>>> There is nothing wrong about your approach, but I try to build
>>> a whole source code documentation like the one I started here:
>>> http://return42.github.io/sphkerneldoc/linux_src_doc/index.html
>>
>> That looks nice, but I'll argue it would not be much worse even if you
>> assumed it's all rst.
>
> A superficial look on the HTML output may give the impression. But in
> the log you will find tons of errors and warnings. My experience is,
> that authors will not consult logs if there are tons of errors from the
> beginning, which carries a decrease in quality. IMO not a good starting
> point.

0-day builds all docs, and checks for new warnings. Even in today's
gpu.tmpl build there's a massive pile of warnings, so yes developers
don't look. But 0-day does, and then developers look at the nice mails
from 0-day. It mostly works to keep out new fail I think.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

\
 
 \ /
  Last update: 2016-05-31 10:21    [W:0.321 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site