Hi Jon, Em Mon, 7 Nov 2016 18:59:15 -0700 Jonathan Corbet <corbet@xxxxxxx> escreveu: > On Thu, 03 Nov 2016 12:52:38 +0200 > Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > > > It's not all about pdf, but with these and Mauro's patches [1] make > > pdfdocs works for me. > > Me too. I've pulled the set, thanks. I rebased by doc branches on my development tree to be on the top of docs-next, in order to identify the pending patches: 1) pdf-fixes branch https://git.linuxtv.org/mchehab/experimental.git/log/?h=pdf-fixes https://lkml.org/lkml/2016/11/7/414 That's the most important one, as it fixes PDF output on media. After applying it, PDF output is OK for me in this branch. On my rebase, there is a minor change: I added a .gitignore on the last patch to make it ignore my generated *.pdf file. Please let me know if you want me to send a version 3 with the rebase + .gitignore or if you have anything to be addressed before a version 3. As I noticed on patch 0/6, it will generate the PDF files via Makefile and add them at the same place the *.png and *.svg files are, as otherwise Sphinx won't get the images. I'm not too happy with that, but we could use some other alternative later, like converting the Makefile logic into a Sphinx extension. 2) parse-headers https://git.linuxtv.org/mchehab/experimental.git/log/?h=parse-headers It contains a single patch that adds Documentation for parse-headers.pl. Just submitted the rebased version of it, independent of kernel-cmd patches. 3) kernel-cmd https://git.linuxtv.org/mchehab/experimental.git/log/?h=kernel-cmd This branch carries a series of patches that depend on the kernel-cmd extension[1], adding documentation for ABI and MAINTAINERS. a) ABI With regards to the ABI documentation, it sounds to be an improvement to have it at the Kernel documentation, so, now that it was decided that kernel-cmd won't be applied, we need an alternative approach to apply them. IMHO, just like we have a get_maintainers.pl, we should have an independent script to parse the ABI documentation, allowing users to run such script directly for things like seeking for the ABI data via command line. That gives us 2 options: 1) automate the ABI documentation production via Makefile; 2) use a copy of kernel-cmd extension that, instead of using a parameter for the command, it will hardcode a call to a "get_abi.pl" script. What approach do you prefer? b) MAINTAINERS While on this tree, it creates a separate perl script to parse maintainers, idea is to add such logic at get_maintainers.pl, if the idea of adding maintainers data at the documentation is accepted. The maintainers file has an introductory chapter that describes part of the submission process. So, IMHO, we should touch it. I think that we should provide at least a summary of it inside the documentation, getting just the mailing list and the git tree where each entry there is hosted. We should also explain the usage of get_maintainer.pl (well, I added a quick description on bug-hunting.rst from user's perspective when tracking a bug, but maybe we need more to explain how a developer should use it - or - cross-link MAINTAINERS with it). If we decide to add MAINTAINERS, my plan is to add a logic at get_maintainer.pl for it to provide the rst output. We can then automate the maintainers.rst generation via Makefile or via another copy of kernel-cmd with a call to get_maintainers.pl hardcoded on it. 4) edac-docs-v4 https://git.linuxtv.org/mchehab/experimental.git/log/?h=edac-docs-v4 This is the EDAC documentation patches. I'll apply on my EDAC tree and submit it during the merge window. We could expect some merge conflicts at linux-next on index.rst files. 5) media-doc-fixes https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-doc-fixes Just one small fix that I'll apply via the media tree. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
