From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: ksummit-discuss@lists.linuxfoundation.org,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>
Subject: Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
Date: Wed, 18 Sep 2019 08:23:26 -0300 [thread overview]
Message-ID: <20190918082326.49a19a24@coco.lan> (raw)
In-Reply-To: <201909170930.B8AD840@keescook>
Em Tue, 17 Sep 2019 09:33:11 -0700
Kees Cook <keescook@chromium.org> escreveu:
> On Tue, Sep 17, 2019 at 10:28:17AM -0300, Mauro Carvalho Chehab wrote:
> > No matter where the profiles will physically be stored, its contents belong
> > to subsystem-specific documentation, and should be visible at the same index
> > file as the kAPI docs is located, as anyone interested on submitting patches
> > for a subsystem should be aware about the subsystem specific policies and
> > details.
>
> That's a good point. I think your other suggestions below address my
> "find them all" case...
>
> > So, my vote is to store them at Documentation/*/<subsystem> (together
> > with the kAPI book).
> >
> > > since there are
> > > two ways someone would want to read profiles:
> > >
> > > 1) a single profile, based on a MAINTAINERS entry which includes the path
> >
> > That is the common case. The problem is that the MAINTAINERS file
> > currently doesn't generate html output. This is not a problem for
> > "old school" devs, but a newbie wanting to collaborate to a single
> > specific subsystem may not notice - or understand - the importance
> > of the MAINTAINERS file[1].
> >
> > [1] btw, that's why I submitted a RFC, several years ago, a patch
> > converting it to ReST - and later - another patch that would be parsing
> > its contents and producing a ReST output.
> >
> > That's, by far, the most relevant usecase for the profiles, as the
> > audience is the ~4k Kernel developers.
>
> Oh yes, having a .rst of the MAINTAINERS file would be pretty great.
> Seems like it could just be a build target (and then dependency) for the
> sphinx targets?
You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,
as:
- The instructions at the top will be badly parsed;
- It will also parse wrong the entries.
On the patches I wrote several years ago, I fixed the instructions
to make them to produce something that would produce a good output.
That's the easiest part.
For the entries contents, the simplest solution would be something like:
diff --git a/MAINTAINERS b/MAINTAINERS
index 6b4bc320e6ab..ae2afb14ae01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -147,4 +147,4 @@ F: drivers/net/ethernet/3com/3c59x.c
-M: David Dillow <dave@thedillows.org>
-L: netdev@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/3com/typhoon*
+:M: David Dillow <dave@thedillows.org>
+:L: netdev@vger.kernel.org
+:S: Maintained
+:F: drivers/net/ethernet/3com/typhoon*
A trivial change for a normal file, but doing this at MAINTAINERS
will be really painful, as it will cause lots of conflicts.
So, IMO, the best way to do it is to have a script (or to teach
get_maintainers.pl) to produce a ReST output that would do the
above.
The latest RFC about that with I sent was this one:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html
I would probably address this on a different way those days.
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.
Thanks,
Mauro
[PATCH RFC] docs: process: add MAINTAINERS file contents
Anyone working with the Kernel need to consider the contents of the
MAINTAINERS file. So, add it to the ReST output.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index e2c9ffc682c5..22e5b42b8470 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -59,6 +59,9 @@ lack of a better place.
volatile-considered-harmful
clang-format
+.. include:: ../../MAINTAINERS
+ :literal:
+
.. only:: subproject and html
Indices
next prev parent reply other threads:[~2019-09-18 11:23 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <156821693963.2951081.11214256396118531359.stgit@dwillia2-desk3.amr.corp.intel.com>
2019-09-13 16:19 ` [PATCH] media: add a subsystem profile documentation Mauro Carvalho Chehab
2019-09-17 3:35 ` single maintainer profile directory (was Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation) Kees Cook
2019-09-17 13:28 ` Mauro Carvalho Chehab
2019-09-17 16:33 ` Kees Cook
2019-09-18 11:23 ` Mauro Carvalho Chehab [this message]
2019-09-18 17:39 ` [Ksummit-discuss] single maintainer profile directory (was " Kees Cook
2019-09-18 18:35 ` Mauro Carvalho Chehab
2019-09-21 19:13 ` Jonathan Corbet
2019-09-21 19:45 ` Mauro Carvalho Chehab
2019-09-23 22:45 ` Kees Cook
2019-09-18 12:36 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Laurent Pinchart
2019-09-18 13:57 ` Mauro Carvalho Chehab
2019-09-18 17:27 ` Laurent Pinchart
2019-09-18 18:48 ` Mauro Carvalho Chehab
2019-09-19 7:08 ` Dan Carpenter
2019-09-20 5:29 ` Joe Perches
2019-09-20 14:09 ` Daniel Vetter
2019-09-19 6:56 ` Dan Carpenter
2019-09-19 7:22 ` Geert Uytterhoeven
2019-09-19 8:49 ` Jani Nikula
2019-09-19 8:58 ` Geert Uytterhoeven
2019-09-19 9:52 ` Jani Nikula
2019-09-20 14:53 ` Laurent Pinchart
2019-09-20 14:59 ` Doug Anderson
2019-09-21 8:56 ` Jani Nikula
2019-09-23 15:58 ` Doug Anderson
2019-09-23 16:04 ` Jonathan Corbet
2019-09-19 9:52 ` Mauro Carvalho Chehab
2019-09-25 17:13 ` Joe Perches
2019-09-25 18:40 ` Kees Cook
2019-09-26 15:14 ` Joe Perches
2019-09-26 15:53 ` Kees Cook
2019-09-26 16:02 ` Joe Perches
2019-09-26 16:24 ` Kees Cook
2019-09-26 10:25 ` Geert Uytterhoeven
2019-09-18 13:59 ` [PATCH v2] " Mauro Carvalho Chehab
2019-09-18 14:07 ` André Almeida
2019-09-18 14:11 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190918082326.49a19a24@coco.lan \
--to=mchehab+samsung@kernel.org \
--cc=corbet@lwn.net \
--cc=keescook@chromium.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).