From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: "Theodore Y. Ts'o" <tytso@mit.edu>,
"Sebastian Duda" <sebastian.duda@fau.de>,
"Pali Rohár" <pali.rohar@gmail.com>,
linux-kernel@vger.kernel.org, lukas.bulwahn@gmail.com
Subject: Re: Status of Subsystems
Date: Wed, 21 Aug 2019 14:10:13 +0200 [thread overview]
Message-ID: <57a7ae11-282f-8b93-355c-4bc839f76b23@metux.net> (raw)
In-Reply-To: <20190820171550.GE10232@mit.edu>
On 20.08.19 19:15, Theodore Y. Ts'o wrote:
Hi,
> There are some files which have no official
> owner, and there are also some files which may be modified by more
> than one subsystem.
hmm, wouldn't it be better to alway have explicit maintainers ?
I recall some discussion few weeks ago on some of my patches, where it
turned out that amm acts as fallback for a lot of code that doesn't have
a maintainer.
@Sebastian: maybe you could also create reports for quickly identifying
those cases.
> We certainly don't talk about "inheritance" when we talk about
> maintainers and sub-maintainers.
What's the exact definition of the term "sub-maintainer" ?
Somebody who's maintaining some defined part of something bigger
(eg. a driver within some subsystem, some platform within some
arch, etc) or kinda deputee maintainer ?
> Furthermore, the relationships,
> processes, and workflows between a particular maintainer and their
> submaintainers can be unique to a particular maintainer.
Can we somehow find some (semi-formal) description for those
relationships and workflows, so it's easier to learn about them
when some is new to some particular area ?
(I'd volounteer maintaining such documentation, if the individual
maintainers feed me the necessary information ;-)).
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
next prev parent reply other threads:[~2019-08-21 12:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 13:05 Status of Subsystems Sebastian Duda
2019-08-20 13:14 ` Pali Rohár
2019-08-20 13:56 ` Sebastian Duda
2019-08-20 14:05 ` Pali Rohár
2019-08-20 14:09 ` Joe Perches
2019-08-20 17:15 ` Theodore Y. Ts'o
2019-08-21 12:10 ` Enrico Weigelt, metux IT consult [this message]
2019-08-22 10:54 ` Sebastian Duda
2019-08-22 14:08 ` Theodore Y. Ts'o
2019-08-22 9:28 ` Sebastian Duda
2019-08-22 12:49 ` Enrico Weigelt, metux IT consult
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=57a7ae11-282f-8b93-355c-4bc839f76b23@metux.net \
--to=lkml@metux.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=pali.rohar@gmail.com \
--cc=sebastian.duda@fau.de \
--cc=tytso@mit.edu \
/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).