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

Mauro Carvalho Chehab
2019-09-21T19:45:18Z

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