On 24/05/19 21:08, Eduardo Habkost wrote:
> On Fri, May 24, 2019 at 08:34:23PM +0200, Paolo Bonzini wrote:
>> On 23/05/19 14:20, John Snow wrote:
>>> OK, if that's where we're at! I just saw the RFC from Peter Maydell and
>>> assumed we were a little further along the decision making process, but
>
On Fri, May 24, 2019 at 08:34:23PM +0200, Paolo Bonzini wrote:
> On 23/05/19 14:20, John Snow wrote:
> > OK, if that's where we're at! I just saw the RFC from Peter Maydell and
> > assumed we were a little further along the decision making process, but
> > maybe not. I'll stay tuned.
>
> For the d
On 23/05/19 14:20, John Snow wrote:
> OK, if that's where we're at! I just saw the RFC from Peter Maydell and
> assumed we were a little further along the decision making process, but
> maybe not. I'll stay tuned.
For the decision making, yes; I think there's consensus to use
kerneldoc. For the "
On 5/22/19 4:20 AM, Paolo Bonzini wrote:
> On 21/05/19 22:37, Eduardo Habkost wrote:
>>> But this is the one we're going with? Do we have a plan for teaching it
>>> not to panic for our use of named custom types?
>>
>> If I understood correctly, the patch from Paolo that I have
>> forwarded to t
On 21/05/19 22:37, Eduardo Habkost wrote:
>> But this is the one we're going with? Do we have a plan for teaching it
>> not to panic for our use of named custom types?
>
> If I understood correctly, the patch from Paolo that I have
> forwarded to this thread is all we need. Are there other issues
On 5/21/19 11:27 AM, Peter Maydell wrote:
> On Tue, 21 May 2019 at 16:18, Markus Armbruster wrote:
>> Anyway. What's so special about QEMU that justifies coming up with our
>> own doc syntax? Other than "we made a hash of it, and cleaning it up
>> would be work".
>
> The major problem as far
On Tue, May 21, 2019 at 04:32:35PM -0400, John Snow wrote:
>
>
> On 5/21/19 11:27 AM, Peter Maydell wrote:
> > On Tue, 21 May 2019 at 16:18, Markus Armbruster wrote:
> >> Anyway. What's so special about QEMU that justifies coming up with our
> >> own doc syntax? Other than "we made a hash of i
On 21/05/19 18:17, Eduardo Habkost wrote:
> On Tue, May 21, 2019 at 12:55:36PM +0200, Paolo Bonzini wrote:
>> On 21/05/19 10:53, Daniel P. Berrangé wrote:
>>> Hawkmoth seems pretty attractive in its output format, but doesn't appear
>>> to be part of either Debian or Fedora distros, so we would hav
On 21/05/19 17:27, Peter Maydell wrote:
>> Anyway. What's so special about QEMU that justifies coming up with our
>> own doc syntax? Other than "we made a hash of it, and cleaning it up
>> would be work".
> The major problem as far as kernel-doc is concerned is that
> it somewhat bakes in the ker
On Tue, May 21, 2019 at 12:55:36PM +0200, Paolo Bonzini wrote:
> On 21/05/19 10:53, Daniel P. Berrangé wrote:
> > Hawkmoth seems pretty attractive in its output format, but doesn't appear
> > to be part of either Debian or Fedora distros, so we would have to bundle
> > it in QEMU I expect. My big
On Tue, 21 May 2019 at 16:18, Markus Armbruster wrote:
> Anyway. What's so special about QEMU that justifies coming up with our
> own doc syntax? Other than "we made a hash of it, and cleaning it up
> would be work".
The major problem as far as kernel-doc is concerned is that
it somewhat bakes
On Tue, May 21, 2019 at 05:18:36PM +0200, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
> > On 21/05/19 10:53, Daniel P. Berrangé wrote:
> [...]
> >> QEMU should pick a tool which is well established / widely used & thus
> >> stands a good chance of being maintained for the long term, as we
Paolo Bonzini writes:
> On 21/05/19 10:53, Daniel P. Berrangé wrote:
[...]
>> QEMU should pick a tool which is well established / widely used & thus
>> stands a good chance of being maintained for the long term, as we don't
>> want to end up relying on abandonware in 5 years time. The kernel-doc
On 21/05/19 11:42, Peter Maydell wrote:
> (The other interesting thing I'd wondered about with generation
> of docs from code comments is whether we would get better
> (ie more accurate, regularly updated) documentation of our
> supported machine models if we generated those parts of the
> docs fro
On Tue, May 21, 2019 at 10:43:04AM +0100, Peter Maydell wrote:
> On Tue, 21 May 2019 at 09:54, Daniel P. Berrangé wrote:
> > Hawkmoth seems pretty attractive in its output format, but doesn't appear
> > to be part of either Debian or Fedora distros, so we would have to bundle
> > it in QEMU I expe
On 21/05/19 10:53, Daniel P. Berrangé wrote:
> Hawkmoth seems pretty attractive in its output format, but doesn't appear
> to be part of either Debian or Fedora distros, so we would have to bundle
> it in QEMU I expect. My big concern there is that there have only been
> 2 contributors to Hawkmoth
On Tue, 21 May 2019 at 09:54, Daniel P. Berrangé wrote:
> Hawkmoth seems pretty attractive in its output format, but doesn't appear
> to be part of either Debian or Fedora distros, so we would have to bundle
> it in QEMU I expect. My big concern there is that there have only been
> 2 contributors
On Mon, 20 May 2019 at 19:41, Eduardo Habkost wrote:
>
> Please welcome GSoC student Gabriel Barreto. Gabriel is going to
> work on QEMU API Documentation Generation[1].
>
> Gabriel's first task is to evaluate our options for extract doc
> comments from C source code and integrate them into Sphin
On Mon, May 20, 2019 at 03:41:08PM -0300, Eduardo Habkost wrote:
> Please welcome GSoC student Gabriel Barreto. Gabriel is going to
> work on QEMU API Documentation Generation[1].
>
> Gabriel's first task is to evaluate our options for extract doc
> comments from C source code and integrate them
On 5/20/19 2:41 PM, Eduardo Habkost wrote:
> Please welcome GSoC student Gabriel Barreto. Gabriel is going to
> work on QEMU API Documentation Generation[1].
>
> Gabriel's first task is to evaluate our options for extract doc
> comments from C source code and integrate them into Sphinx
> docum
Please welcome GSoC student Gabriel Barreto. Gabriel is going to
work on QEMU API Documentation Generation[1].
Gabriel's first task is to evaluate our options for extract doc
comments from C source code and integrate them into Sphinx
documentation. I saw that Peter has experimented with kernel-d
21 matches
Mail list logo
