Am 27.06.2016 um 19:08 schrieb Mauro Carvalho Chehab :
> Em Mon, 27 Jun 2016 08:15:28 +0200
> Markus Heiser escreveu:
>
>> Am 24.06.2016 um 12:40 schrieb Mauro Carvalho Chehab
>> :
>>
>>> Em Tue, 31 May 2016 12:16:25 +0200
>>> Markus Heiser escreveu:
>>>
Am 30.05.2016 um 23:23 schrieb
Em Mon, 27 Jun 2016 08:15:28 +0200
Markus Heiser escreveu:
> Am 24.06.2016 um 12:40 schrieb Mauro Carvalho Chehab
> :
>
> > Em Tue, 31 May 2016 12:16:25 +0200
> > Markus Heiser escreveu:
> >
> >> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab
> >> :
> >>
> >>> Em Mon, 30 May 2016
Am 24.06.2016 um 12:40 schrieb Mauro Carvalho Chehab :
> Em Tue, 31 May 2016 12:16:25 +0200
> Markus Heiser escreveu:
>
>> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab
>> :
>>
>>> Em Mon, 30 May 2016 23:05:34 +0300
>>> Jani Nikula escreveu:
>>>
> I worry a little bit in that reS
Em Tue, 31 May 2016 12:16:25 +0200
Markus Heiser escreveu:
> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab
> :
>
> > Em Mon, 30 May 2016 23:05:34 +0300
> > Jani Nikula escreveu:
> >
> >>> I worry a little bit in that reST will be only one more toolchain
> >>> beside DocBook .. in th
On Fri, 03 Jun 2016, Jonathan Corbet wrote:
> On Fri, 3 Jun 2016 22:24:03 +0200
> Daniel Vetter wrote:
>
>> > This is maybe a job for a separate tool. A related issue is the (fairly
>> > frequent) "oh look, none of the comments in $FILE are being used"
>> > realization that seems to happen fairl
On Fri, 03 Jun 2016, Jonathan Corbet wrote:
> [So I'm finally trying to get into this for real, hopefully I won't be
> interrupted too many times...expect a few mails as I catch up.]
>
> On Fri, 20 May 2016 16:39:31 +0300
> Jani Nikula wrote:
>
>> There are a few tradeoffs, of course. First, this
On Sat, 04 Jun 2016, Jonathan Corbet wrote:
> On Mon, 30 May 2016 23:05:34 +0300
> Jani Nikula wrote:
>
>> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
>> propose to merge at this time. There's the Sphinx configuration, kernel
>> build integration, Sphinx kernel-doc extens
On Fri, Jun 3, 2016 at 11:04 PM, Jonathan Corbet wrote:
> On Mon, 30 May 2016 23:05:34 +0300
> Jani Nikula wrote:
>
>> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
>> propose to merge at this time. There's the Sphinx configuration, kernel
>> build integration, Sphinx kerne
On Mon, 30 May 2016 23:05:34 +0300
Jani Nikula wrote:
> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
> propose to merge at this time. There's the Sphinx configuration, kernel
> build integration, Sphinx kernel-doc extension, tons of kernel-doc
> updates, etc.
OK, I do be
On Fri, 3 Jun 2016 22:24:03 +0200
Daniel Vetter wrote:
> > This is maybe a job for a separate tool. A related issue is the (fairly
> > frequent) "oh look, none of the comments in $FILE are being used"
> > realization that seems to happen fairly often. It would be nice to check
> > for that, but
On Fri, Jun 3, 2016 at 10:16 PM, Jonathan Corbet wrote:
>
>> Second, we lose support for the !C docproc directive to check
>> that all kernel-doc comments in a file are used. This is probably
>> something we'd like to have back in the future, but at this time I think
>> it's an acceptable tradeoff
[So I'm finally trying to get into this for real, hopefully I won't be
interrupted too many times...expect a few mails as I catch up.]
On Fri, 20 May 2016 16:39:31 +0300
Jani Nikula wrote:
> There are a few tradeoffs, of course. First, this requires that the
> EXPORT_SYMBOL markers are placed im
On Wed, Jun 1, 2016 at 3:07 AM, Jonathan Corbet wrote:
> On Mon, 30 May 2016 11:10:26 +0200
> Daniel Vetter wrote:
>
>> I think next steps is to get this merged into docs-next, with a stable
>> tag, so that I can pull it into drm-misc.
>
> So, I want to take another look at this, which probably w
On Mon, 30 May 2016 11:10:26 +0200
Daniel Vetter wrote:
> I think next steps is to get this merged into docs-next, with a stable
> tag, so that I can pull it into drm-misc.
So, I want to take another look at this, which probably will need another
day or two before it can happen. First impressio
Am 31.05.2016 um 12:30 schrieb Jani Nikula :
> On Tue, 31 May 2016, Markus Heiser wrote:
>> Am 31.05.2016 um 10:07 schrieb Daniel Vetter :
>>> 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 lo
On Tue, 31 May 2016, Markus Heiser wrote:
> Am 31.05.2016 um 10:07 schrieb Daniel Vetter :
>> 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 n
Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab :
> Em Mon, 30 May 2016 23:05:34 +0300
> Jani Nikula escreveu:
>
>>> I worry a little bit in that reST will be only one more toolchain
>>> beside DocBook .. in the long term, kernel's documentation
>>> should get rid of all the DocBook arti
Am 31.05.2016 um 10:07 schrieb Daniel Vetter :
> On Tue, May 31, 2016 at 9:27 AM, Markus Heiser
> 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 .
On Tue, May 31, 2016 at 9:27 AM, Markus Heiser
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-do
Am 30.05.2016 um 22:05 schrieb Jani Nikula :
> On Mon, 30 May 2016, Markus Heiser wrote:
>> Am 30.05.2016 um 16:46 schrieb Jani Nikula :
>>> I am not proposing to merge the documents that I've converted mostly as
>>> samples in the branch. I needed something to demonstrate the build is
>>> sane.
Em Mon, 30 May 2016 23:05:34 +0300
Jani Nikula escreveu:
> > I worry a little bit in that reST will be only one more toolchain
> > beside DocBook .. in the long term, kernel's documentation
> > should get rid of all the DocBook artifacts and for this a more
> > comprehensive solution is needed.
On Mon, 30 May 2016, Markus Heiser wrote:
> Am 30.05.2016 um 16:46 schrieb Jani Nikula :
>> I am not proposing to merge the documents that I've converted mostly as
>> samples in the branch. I needed something to demonstrate the build is
>> sane.
>
>> The authors of the DocBook documents should mak
Am 30.05.2016 um 16:46 schrieb Jani Nikula :
> On Mon, 30 May 2016, Markus Heiser wrote:
>> Here my 5cents about Jani's patch series:
>>
>> 1. Migration implementations should not be a part of the kernel tree
>
> If you're referring to the conversion scripts, I don't care either
> way. It's pr
I concur with Jani on all points, just want to follow-up here.
On Mon, May 30, 2016 at 4:46 PM, Jani Nikula wrote:
>> Many of the facts mentioned above have been covered in my POC at
>> https://github.com/return42/sphkerneldoc ... On others,
>> like 5. I'am working on
>>
>>> I've had a few m
On Mon, 30 May 2016, Markus Heiser wrote:
> Here my 5cents about Jani's patch series:
>
> 1. Migration implementations should not be a part of the kernel tree
If you're referring to the conversion scripts, I don't care either
way. It's probably helpful to have them until everything is converted,
Hi,
sorry for my temporary absence, I have been on holiday the last weeks :-)
Am 30.05.2016 um 11:10 schrieb Daniel Vetter :
> On Sun, May 29, 2016 at 10:33 PM, Jani Nikula wrote:
>> On Fri, 20 May 2016, Jani Nikula wrote:
>>> At this time I've put most effort into the configuration and build
On Sun, May 29, 2016 at 10:33 PM, Jani Nikula wrote:
> On Fri, 20 May 2016, Jani Nikula wrote:
>> At this time I've put most effort into the configuration and build side
>> of things, solving the problems described above, and handling missing
>> tools and packages gracefully. There are still issu
On Fri, 20 May 2016, Jani Nikula wrote:
> At this time I've put most effort into the configuration and build side
> of things, solving the problems described above, and handling missing
> tools and packages gracefully. There are still issues to be ironed out
> in a) the kernel-doc script rst outpu
28 matches
Mail list logo
