lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKMK7uFPSaH7swp4F+=KhMupFa_6SSPoHMTA4tc8J7Ng1HzABQ@mail.gmail.com>
Date:	Tue, 3 May 2016 16:31:14 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Jonathan Corbet <corbet@....net>,
	Markus Heiser <markus.heiser@...marit.de>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Jani Nikula <jani.nikula@...el.com>,
	Dan Allen <dan@...ndevise.io>,
	Russel Winder <russel@...der.org.uk>,
	Keith Packard <keithp@...thp.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Hans Verkuil <hverkuil@...all.nl>,
	"linux-media@...r.kernel.org linux-media" 
	<linux-media@...r.kernel.org>,
	Graham Whaley <graham.whaley@...ux.intel.com>
Subject: Re: Kernel docs: muddying the waters a bit

Hi all,

So sounds like moving ahead with rst/sphinx is the option that should
allow us to address everyone's concerns eventually? Of course the
first one won't have it all (media seems really tricky), but I'd like
to get something awesome in this area closer to mainline. I'm stalling
on typing more fancyful gpu docs right now (with tables, pictures and
stuff) since that would require a pile of needless work to redo when
we switch a few times more ;-)

And Jani also wants to get this in, but he doesn't really want to
spend more effort on a system that can't be merged.

So sphinx/rst y/n? Jon, is that ok with you from the doc maintainer pov?

Cheers, Daniel

On Wed, Apr 27, 2016 at 4:28 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> On Tue, Apr 12, 2016 at 4:46 PM, Jonathan Corbet <corbet@....net> wrote:
>> On Fri, 8 Apr 2016 17:12:27 +0200
>> Markus Heiser <markus.heiser@...marit.de> wrote:
>>
>>> motivated by this MT, I implemented a toolchain to migrate the kernel’s
>>> DocBook XML documentation to reST markup.
>>>
>>> It converts 99% of the docs well ... to gain an impression how
>>> kernel-docs could benefit from, visit my sphkerneldoc project page
>>> on github:
>>>
>>>   http://return42.github.io/sphkerneldoc/
>>
>> So I've obviously been pretty quiet on this recently.  Apologies...I've
>> been dealing with an extended death-in-the-family experience, and there is
>> still a fair amount of cleanup to be done.
>>
>> Looking quickly at this work, it seems similar to the results I got.  But
>> there's a lot of code there that came from somewhere?  I'd put together a
>> fairly simple conversion using pandoc and a couple of short sed scripts;
>> is there a reason for a more complex solution?
>>
>> Thanks for looking into this, anyway; I hope to be able to focus more on
>> it shortly.
>
> Hi Jon,
>
> Thanks for digging into this. FWIW, here is my $0.02. I've been
> working on restarting the devicetree specification, and after looking
> at both reStructuredText and Asciidoc(tor) I thought I liked the
> Asciidoc markup better, so chose that. I then proceeded to spend weeks
> trying to get reasonable output from the toolchain. When I got fed up
> and gave Sphinx a try, I was up and running with reasonable PDF and
> HTML output in a day and a half.
>
> Honestly, in the end I think we could make either tool do what is
> needed of it. However, my impression after trying to do a document
> that needs to have nice publishable output with both tools is that
> Sphinx is easier to work with, simpler to extend, better supported. My
> vote is firmly behind Sphinx/reStructuredText.
>
> g.



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ