public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: "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: Thu, 22 Aug 2019 10:08:07 -0400	[thread overview]
Message-ID: <20190822140807.GA2730@mit.edu> (raw)
In-Reply-To: <57a7ae11-282f-8b93-355c-4bc839f76b23@metux.net>

On Wed, Aug 21, 2019 at 02:10:13PM +0200, Enrico Weigelt, metux IT consult wrote:
> 
> > 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 ?

"It varies".  That was my whole point.

And there are some files, such as fs/fs-writeback.c which is rarely
touched by Al Viro (the fs maintainer) and mm/page-writeback.c (which
is rarely touched by the MM maintainers).  Both of these files are
related to writeback of buffered writeback, and the people who touch
are a smaller set of file system maintainers, and discussions
generally happen on linux-fsdevel.

Which git trees these changes go up through are also not necessarily
as specified by the maintainers files, for a number of reasons,
including avoiding git merge conflicts.

There is a desire to document more of these branch specific issues
(for example, the Networking branch has very specific times when
patches will be accepted for review) but that's a work in progress.
And I think a lot of people have been nervous about documenting
things, since once documented, there are process mavens will say, "you
documented it as FOO" and now you are doing BAR and complain that it's
a process violation, when in fact all rules have exceptions, and
sometimes those exceptions and when they get invoked are complicated.
Worse yet is when the documentation isn't precisely correct, and then
they get taken as gospel truth.

That doesn't mean we shouldn't document them, but a lot of care needs
to be taken.  It's also hard because the people who know the processes
the best are also some of the more busy people, and the downside if
the processes aren't documented *precisely* with most exceptions
documented, etc., are the same people.  (See the discussion over what
does "Reviewed-by" mean, and what meaning attaches to it as an example
where IMHO how it was used, and how it was documented, were not the
same thing.)

Cheers,

					- Ted

  parent reply	other threads:[~2019-08-22 14:08 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
2019-08-22 10:54         ` Sebastian Duda
2019-08-22 14:08         ` Theodore Y. Ts'o [this message]
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=20190822140807.GA2730@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@metux.net \
    --cc=lukas.bulwahn@gmail.com \
    --cc=pali.rohar@gmail.com \
    --cc=sebastian.duda@fau.de \
    /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