All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Linaro MM SIG Mailman List <linaro-mm-sig@lists.linaro.org>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [RFC 0/4] doc: dma-buf: sphinx conversion and cleanup
Date: Fri, 12 Aug 2016 10:38:04 +0200	[thread overview]
Message-ID: <20160812083804.GP6232@phenom.ffwll.local> (raw)
In-Reply-To: <CAO_48GEUzviZT0HMa8UhT+jN-eNmbTyTdnBs9SZFXz2fJ0m-7Q@mail.gmail.com>

On Fri, Aug 12, 2016 at 12:05:04PM +0530, Sumit Semwal wrote:
> Hi Jon!
> 
> On 11 August 2016 at 20:06, Jonathan Corbet <corbet@lwn.net> wrote:
> > On Thu, 11 Aug 2016 16:17:56 +0530
> > Sumit Semwal <sumit.semwal@linaro.org> wrote:
> >
> >> Convert dma-buf documentation over to sphinx; also cleanup to
> >> address sphinx warnings.
> >>
> >> While at that, convert dma-buf-sharing.txt as well, and make it the
> >> dma-buf API guide.
> >
> > Thanks for working to improve the documentation!  I do have a few overall
> > comments...
> >
> Thank you for your review, and comments; my responses are inline.
> 
> >  - The two comment fixes are a separate thing that should go straight to
> >    the dma-buf maintainer, who is ... <looks> ... evidently somebody
> >    familiar to you :)  I assume you'll merge those two directly?
> >
> Yes, of course :) - I will merge them directly, and will remove them
> from v2 of this series.
> 
> >  - It looks like you create a new RST document but leave the old one in
> >    place.  Having two copies of the document around can only lead to
> >    confusion, so I think the old one should go.
> >
> Agreed on this as well; will correct it.
> 
> >  - I really wonder if we want to start carving pieces out of
> >    device-drivers.tmpl in this way.  I guess I would rather see the
> >    conversion of that book and the better integration of the other docs
> >    *into* it.  One of the goals of this whole thing is to unify our
> >    documentation, not to reinforce the silos.
> >
> I should've mentioned it in the cover letter - my intention of taking
> the dma-buf pieces out was to focus on these first while moving to
> sphinx.
> 
> My proposal would be, if all the device driver section owners could
> take the relevant pieces, convert them to sphinx (ironing out warnings
> etc in the process), then we can again 'bind' them together into the
> device drivers book in rst format.
> This breaks the documentation conversion task into manageable pieces
> that can be handled independently, and gives everyone flexibility to
> work on their schedules.
> 
> This should also help in a good technical re-look at the content by
> subsystem developers, and make any documentation updates as required.
> The beauty of sphinx should allow us this, I think? Just my 2 cents.

I already tried to trick Sumit into converting the entire
device-drivers.tmpl, but he didn't take the bait ;-)

I think just extracting dma-buf stuff (dma_buf, fence, reservation and all
that) is ok though, it is a fairly stand-alone topic.
-Daniel

> 
> > Does that make sense?
> >
> I do hope that my proposal above finds some merit with everyone.
> 
> > Thanks,
> >
> > jon
> 
> BR,
> Sumit.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-doc@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	LKML <linux-kernel@vger.kernel.org>,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	Linaro MM SIG Mailman List <linaro-mm-sig@lists.linaro.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [RFC 0/4] doc: dma-buf: sphinx conversion and cleanup
Date: Fri, 12 Aug 2016 10:38:04 +0200	[thread overview]
Message-ID: <20160812083804.GP6232@phenom.ffwll.local> (raw)
In-Reply-To: <CAO_48GEUzviZT0HMa8UhT+jN-eNmbTyTdnBs9SZFXz2fJ0m-7Q@mail.gmail.com>

On Fri, Aug 12, 2016 at 12:05:04PM +0530, Sumit Semwal wrote:
> Hi Jon!
> 
> On 11 August 2016 at 20:06, Jonathan Corbet <corbet@lwn.net> wrote:
> > On Thu, 11 Aug 2016 16:17:56 +0530
> > Sumit Semwal <sumit.semwal@linaro.org> wrote:
> >
> >> Convert dma-buf documentation over to sphinx; also cleanup to
> >> address sphinx warnings.
> >>
> >> While at that, convert dma-buf-sharing.txt as well, and make it the
> >> dma-buf API guide.
> >
> > Thanks for working to improve the documentation!  I do have a few overall
> > comments...
> >
> Thank you for your review, and comments; my responses are inline.
> 
> >  - The two comment fixes are a separate thing that should go straight to
> >    the dma-buf maintainer, who is ... <looks> ... evidently somebody
> >    familiar to you :)  I assume you'll merge those two directly?
> >
> Yes, of course :) - I will merge them directly, and will remove them
> from v2 of this series.
> 
> >  - It looks like you create a new RST document but leave the old one in
> >    place.  Having two copies of the document around can only lead to
> >    confusion, so I think the old one should go.
> >
> Agreed on this as well; will correct it.
> 
> >  - I really wonder if we want to start carving pieces out of
> >    device-drivers.tmpl in this way.  I guess I would rather see the
> >    conversion of that book and the better integration of the other docs
> >    *into* it.  One of the goals of this whole thing is to unify our
> >    documentation, not to reinforce the silos.
> >
> I should've mentioned it in the cover letter - my intention of taking
> the dma-buf pieces out was to focus on these first while moving to
> sphinx.
> 
> My proposal would be, if all the device driver section owners could
> take the relevant pieces, convert them to sphinx (ironing out warnings
> etc in the process), then we can again 'bind' them together into the
> device drivers book in rst format.
> This breaks the documentation conversion task into manageable pieces
> that can be handled independently, and gives everyone flexibility to
> work on their schedules.
> 
> This should also help in a good technical re-look at the content by
> subsystem developers, and make any documentation updates as required.
> The beauty of sphinx should allow us this, I think? Just my 2 cents.

I already tried to trick Sumit into converting the entire
device-drivers.tmpl, but he didn't take the bait ;-)

I think just extracting dma-buf stuff (dma_buf, fence, reservation and all
that) is ok though, it is a fairly stand-alone topic.
-Daniel

> 
> > Does that make sense?
> >
> I do hope that my proposal above finds some merit with everyone.
> 
> > Thanks,
> >
> > jon
> 
> BR,
> Sumit.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-08-12  8:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-11 10:47 [RFC 0/4] doc: dma-buf: sphinx conversion and cleanup Sumit Semwal
2016-08-11 10:47 ` [RFC 1/4] dma-buf/fence: kerneldoc: remove unused struct members Sumit Semwal
2016-08-11 10:47   ` Sumit Semwal
2016-08-11 10:47 ` [RFC 2/4] dma-buf/fence: kerneldoc: remove spurious section header Sumit Semwal
2016-08-11 10:47   ` Sumit Semwal
2016-08-12  8:44   ` Daniel Vetter
2016-08-12  8:44     ` Daniel Vetter
2016-08-11 10:47 ` [RFC 3/4] Documentation: move dma-buf documentation to rst Sumit Semwal
2016-08-11 10:47   ` Sumit Semwal
2016-08-11 11:47   ` Jani Nikula
2016-08-11 11:47     ` Jani Nikula
2016-08-11 12:31     ` Sumit Semwal
2016-08-11 11:58   ` Markus Heiser
2016-08-11 12:12     ` Markus Heiser
2016-08-11 12:12       ` Markus Heiser
2016-08-11 12:49     ` Sumit Semwal
2016-08-11 12:49       ` Sumit Semwal
2016-08-11 10:48 ` [RFC 4/4] Documentation/sphinx: link dma-buf rsts Sumit Semwal
2016-08-11 10:48   ` Sumit Semwal
2016-08-11 14:36 ` [RFC 0/4] doc: dma-buf: sphinx conversion and cleanup Jonathan Corbet
2016-08-11 19:13   ` rst htmldocs on kernel.org Lukas Wunner
2016-08-15 22:21     ` Jonathan Corbet
2016-08-16  8:24       ` Lukas Wunner
2016-08-12  6:35   ` [RFC 0/4] doc: dma-buf: sphinx conversion and cleanup Sumit Semwal
2016-08-12  6:35     ` Sumit Semwal
2016-08-12  8:38     ` Daniel Vetter [this message]
2016-08-12  8:38       ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2016-08-11 10:45 Sumit Semwal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160812083804.GP6232@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.