From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754919AbbILVYw (ORCPT ); Sat, 12 Sep 2015 17:24:52 -0400 Received: from tex.lwn.net ([70.33.254.29]:35341 "EHLO vena.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751914AbbILVYv (ORCPT ); Sat, 12 Sep 2015 17:24:51 -0400 Date: Sat, 12 Sep 2015 15:24:49 -0600 From: Jonathan Corbet To: Danilo Cesar Lemes de Paula Cc: Daniel Vetter , Andrew Morton , Johannes Berg , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, intel-gfx , dri-devel Subject: Re: [PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements Message-ID: <20150912152449.1cdc1710@lwn.net> In-Reply-To: <1441656124-8997-1-git-send-email-danilo.cesar@collabora.co.uk> References: <1441656124-8997-1-git-send-email-danilo.cesar@collabora.co.uk> Organization: LWN.net X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 7 Sep 2015 17:01:58 -0300 Danilo Cesar Lemes de Paula wrote: > The following series contains: > * kernel-doc: markdown support and improvements. OK, I've spent a while looking this stuff over. I like the general idea, but I do have a couple of concerns. 1 Installing pandoc on a Fedora system wants to drag in 70(!) packages for 100MB of total stuff. Installing it on Arch is ... well ... enough to make you want to switch to Fedora. If we add a dependency on a tool this massive, people are going to complain, loudly. Have you looked at using something like cmark instead? I don't know the tool well, but it seems like it can do the job simply enough. It's focused, written in C, and doesn't drag in a diskful of Haskell stuff. There's lot of other converters out there too, I'm not tied to this one (though I think CommonMark deserves support), but I do think this question needs to be considered. 2 We're constructing an increasingly complicated document-processing mechanism with a lot of independently moving parts. What if we converted the whole document to markdown and dispensed with the XML part altogether? Making the source files simpler and dispensing with the xmlto requirement would be a big win, IMO. I will not make #2 be a precondition to getting some form of this work merged, but I would like to have a good answer for #1. Adding such a heavyweight dependency (even as an optional one) needs to have a pretty good story behind it. Thanks, jon