linux-kernel - Re: Status of Subsystems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190822140807.GA2730@mit.edu>
Date:   Thu, 22 Aug 2019 10:08:07 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc:     Sebastian Duda <sebastian.duda@....de>,
        Pali Rohár <pali.rohar@...il.com>,
        linux-kernel@...r.kernel.org, lukas.bulwahn@...il.com
Subject: Re: Status of Subsystems

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