From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034066AbcIWRvE (ORCPT ); Fri, 23 Sep 2016 13:51:04 -0400 Received: from ec2-52-27-115-49.us-west-2.compute.amazonaws.com ([52.27.115.49]:43635 "EHLO s-opensource.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030267AbcIWRvC (ORCPT ); Fri, 23 Sep 2016 13:51:02 -0400 Date: Fri, 23 Sep 2016 14:50:56 -0300 From: Mauro Carvalho Chehab To: Joe Perches Cc: Linux Doc Mailing List , Jonathan Corbet , Mauro Carvalho Chehab , Mauro Carvalho Chehab , Linux Kernel Mailing List Subject: Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS Message-ID: <20160923145056.6cfaf68e@vento.lan> In-Reply-To: <1474647994.1849.1.camel@perches.com> References: <20160923120733.546a4b7a@vento.lan> <1474647994.1849.1.camel@perches.com> Organization: Samsung X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, 23 Sep 2016 09:26:34 -0700 Joe Perches escreveu: > On Fri, 2016-09-23 at 12:07 -0300, Mauro Carvalho Chehab wrote: > > So, let's use an unusual approach: manually convert the > > text at the MAINTAINERS file head, adding it at a new > > Documentation/user/MAINTAINERS.rst, and include, as a code > > block, the rest of MAINTAINERS contents, with only the > > contents of the maintainers entries. > > > > There's a side effect of this approach: now, if the > > explanation text at the MAINTAINERS file is touched, it should be > > modified also at the Documentation/user/MAINTAINERS.rst file. > > Yet, as the number of changes there are small, this > > should be manageable. > > couldn't this be a generated file from some awk script instead > of being duplicated content with a plea to be kept in sync? Yes, using a script (awk/perl/bash/python/....) is another alternative. In such case, we would need to either generate it via Makefile or to have a Sphinx extension that would tell what script to run. I actually think that a generic include-like Sphinx extension that would run a script and use its result as an included text could be interesting, as it would be a way to get rid of the Documentation/media Makefile. Thanks, Mauro