Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)

[Mauro Carvalho Chehab <mchehab+samsung@kernel.org>]

Em Sat, 21 Sep 2019 13:13:07 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> On Wed, 18 Sep 2019 08:23:26 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> 
> > A simple/lazy solution would be to apply the enclosed patch - or a
> > variant of it that would place the contents of MAINTAINERS outside
> > process/index.html, and add instructions about how to use
> > get_maintainers.pl.
> > 
> > Jon,
> > 
> > Please let me know if you're willing to accept something like that.  
> 
> [Sorry for the slowness, I'm kind of tuned out this week]
> 
> I guess we could do that as a short-term thing.
> 
> In truth, though, this thing is a database; printing it out linearly is
> perhaps not the best thing we could do.  There should be better ways we
> could provide access to it.

Yeah, as this is a database, instead of just outputting it on a
formatted way, it is possible to generate other types of output.

We could, for example, have an extension with would implement something like:

	.. maintainers:: <subdir>

Which would call get-maintainers in order to parse a subsystem-specific
set of entries and printing the maintainership details.

This could be added at the subsystem-specific profile, for the subsystems
that have it.

> 
> Also, that file is nearly 18K lines long.  If some unsuspecting person
> generates a PDF and prints it, they're going to get something along the
> lines of 300 pages of MAINTAINERS, which may not quite be what they had
> in mind.  It costs (almost) nothing to put that into HTML output, but
> other formats could be painful.

Even if we go for adding a Sphinx tag that would produce a parsed
output for a system-specific profile, we'll still have several other
subsystems that won't have a profile for a while, so I would still 
consider having somewhere an output with its contents. Yeah, someone
might be tempted to print it, but we could place it on a separate PDF,
in order to minimize the risks of someone printing the 300+ pages.

> 
> So I dunno, we need to think this through a bit...


> 
> jon



Thanks,
Mauro