FYI
Am 07.06.2016 um 09:54 schrieb Daniel Vetter :
> On Mon, Jun 6, 2016 at 6:32 PM, Markus Heiser
> wrote:
>> From: "Heiser, Markus"
>>
> I'm still not sold on the vintage-kerneldoc idea. At least in my
> experience (after first converting to asciidoc and now to sphinx) this
> is a non-issue
On Fri, 10 Jun 2016, Markus Heiser wrote:
> Am 08.06.2016 um 21:49 schrieb Jonathan Corbet :
>> But please,
>> at this point, let's build on Jani's work and go from there. Things have
>> waited for long enough while we've gone around on this; I think what we
>> have is a good starting point.
>
>
Am 08.06.2016 um 21:49 schrieb Jonathan Corbet :
> So I've finally gotten a chance to make another pass over this stuff.
>
> Markus, your enthusiasm is great; I'm hoping you'll do great things
> helping us to improve the kernel's documentation toolchain.
With 7 years DocBook and 8 years reST
So I've finally gotten a chance to make another pass over this stuff.
Markus, your enthusiasm is great; I'm hoping you'll do great things
helping us to improve the kernel's documentation toolchain. But please,
at this point, let's build on Jani's work and go from there. Things have
waited for lo
Am 07.06.2016 um 13:09 schrieb Jani Nikula :
> On Tue, 07 Jun 2016, Markus Heiser wrote:
>> Am 07.06.2016 um 10:59 schrieb Jani Nikula :
>>> One of the key arguments against too much splitting that hasn't been
>>> mentioned is that despite all the fine output Sphinx can produce, we
>>> have plen
Hi all,
sorry I forgot to mentioning that I have not yet add the Makefile.reST
to the root Makefile. To test, please give the srctree environment in the
command line. E.g:
cd /share/linux/Documentation
srctree=/share/linux make -f Makefile.reST books/kernel-doc-HOWTO.html
-- Markus --
Am
On Tue, 07 Jun 2016, Markus Heiser wrote:
> Am 07.06.2016 um 10:59 schrieb Jani Nikula :
>> One of the key arguments against too much splitting that hasn't been
>> mentioned is that despite all the fine output Sphinx can produce, we
>> have plenty of people who couldn't care less about running Sph
Am 07.06.2016 um 10:59 schrieb Jani Nikula :
> On Tue, 07 Jun 2016, Daniel Vetter wrote:
>> I think getting the flat-table directive landed would be great. We
>> have a similarly annoying table in gpu.tmpl where the ascii-art tables
>> fall short and are annoying. We want to split it up, but tha
Am 07.06.2016 um 09:54 schrieb Daniel Vetter :
> On Mon, Jun 6, 2016 at 6:32 PM, Markus Heiser
> wrote:
>> From: "Heiser, Markus"
>>
>> Hi Jonathan, Jani, all -
>>
>> I merged the work from sphkerneldoc POC [1], into branch (on v4.7-rc2)
>>
>>git://github.com/return42/linux.git linux-do
On Tue, 07 Jun 2016, Daniel Vetter wrote:
> I think getting the flat-table directive landed would be great. We
> have a similarly annoying table in gpu.tmpl where the ascii-art tables
> fall short and are annoying. We want to split it up, but that's not a
> short-term solution suitable for convers
On Mon, Jun 6, 2016 at 6:32 PM, Markus Heiser wrote:
> From: "Heiser, Markus"
>
> Hi Jonathan, Jani, all -
>
> I merged the work from sphkerneldoc POC [1], into branch (on v4.7-rc2)
>
> git://github.com/return42/linux.git linux-doc-reST
>
> The specification of the implementation is the (new)
From: "Heiser, Markus"
Hi Jonathan, Jani, all -
I merged the work from sphkerneldoc POC [1], into branch (on v4.7-rc2)
git://github.com/return42/linux.git linux-doc-reST
The specification of the implementation is the (new) kernel-doc-HOWTO book which
is a part of the patch series (also onl
12 matches
Mail list logo
