All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Markus Heiser <markus.heiser@darmarit.de>,
	Dave Airlie <airlied@gmail.com>,
	Jani Nikula <jani.nikula@intel.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	Keith Packard <keithp@keithp.com>,
	LKML Mailing List <linux-kernel@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [GIT PULL] doc: sphinx-4.8 DocBook to reST movement on Jon's docs-next
Date: Wed, 29 Jun 2016 17:57:45 -0300	[thread overview]
Message-ID: <20160629175745.554c93a9@recife.lan> (raw)
In-Reply-To: <20160629115209.596ffd8b@lwn.net>

Em Wed, 29 Jun 2016 11:52:09 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> > 2. What is the best way to ship these migrations
> > 
> > or better I asked, what is your recommendation for a
> > migration strategy. Jani says, that this better belongs
> > to authors, but I have a doubt that we end with the
> > migration in the next years, if we wait about every author.
> > I think, supporting both infrastructures - the xml and the
> > reST - over a long period is not the best option. What is
> > your recommendation on this?  
> 
> I think we need to give maintainers the first shot at doing the conversion;
> in any case, I don't think we can just force it through without their
> cooperation.  And, honestly, while we're still groping around in this
> space, I think it's fine if we don't have lots of conversions right away.
> The ones that go more slowly will benefit from what we learn with the easy
> ones.
> 
> You could certainly talk to maintainers and see if they would like
> assistance with specific books.  Helping Mauro to get his tables done
> without going totally nuts would be a great first step, IMO.

Yeah, going to each maintainer is the best way, as we're the ones
that will be bothered if something goes wrong on the documentation
(and code) that we maintain.

In the specific case of media stuff, the first step is to get the
flat-tree support and to put the migrated documentation on a separate
directory. Unfortunately, I have two sets of topic branches for 4.8,
and they both touch at the media docbook (and nothing prevents that
similar things to happen on 4.9 or any other version).

So, my plan is to keep both reST and docbook on Kernel for a while,
until be sure that everything is properly migrated.

Yet, I'm not sure if we should keep the migration scripts at the
Kernel tree, or if the best is to keep them in separate, as I
intend to not take more than one Kernel version to finish the
conversion. At least for media docbook, this will be a one-time
conversion.

So, I really appreciate if you could send me the patches with
the converted media documentation that you did. I'll merge it
after Jonathan applies the flat-tree patch on his tree, and
start reviewing and fixing the documentation over the main
branch. I'll need to track the topic branch changes at the
Docbook, to apply them again at the master tree, once they
gets merged during the 4.8 window. Thankfully, there aren't
complex elements on such changes (as far as I remember).

If everything goes right, by -rc2 or -rc3 I'll likely be dropping
the DocBook/media from my tree.

--  
Thanks,
Mauro

  reply	other threads:[~2016-06-29 20:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-28 16:41 [GIT PULL] doc: sphinx-4.8 DocBook to reST movement on Jon's docs-next Markus Heiser
2016-06-28 19:05 ` Jani Nikula
2016-06-29 11:06   ` Markus Heiser
2016-06-29 13:15     ` Jani Nikula
2016-06-29 16:48       ` Markus Heiser
2016-06-29 16:24 ` Jonathan Corbet
2016-06-29 17:35   ` Markus Heiser
2016-06-29 17:52     ` Jonathan Corbet
2016-06-29 20:57       ` Mauro Carvalho Chehab [this message]
2016-06-30  9:25         ` Markus Heiser
2016-06-30 10:18           ` Mauro Carvalho Chehab
2016-06-30  8:53       ` Markus Heiser

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=20160629175745.554c93a9@recife.lan \
    --to=mchehab@osg.samsung.com \
    --cc=airlied@gmail.com \
    --cc=corbet@lwn.net \
    --cc=grant.likely@secretlab.ca \
    --cc=hverkuil@xs4all.nl \
    --cc=jani.nikula@intel.com \
    --cc=keithp@keithp.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    --cc=rdunlap@infradead.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.