linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).