Re: [Ksummit-discuss] Topics for the Maintainer's Summit

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Thu, Sep 05, 2019 at 10:01:26AM +0300, Jani Nikula wrote:
> 
> At least I've tried (and likely also failed) to merely describe what we
> do, what works for us, how we think we benefit, and how it just might
> benefit others. It's just sad when the pushback is strong enough to
> discourage people from sharing their experiences to begin with.
> 
> I know I've reduced talking about it outside of the GPU people bubble.

I seem to recall at least one over-enthusiastic driver developer who
was so sure that group maintainership was The Way To Go that there may
have been, statements of the effect that everyone else should follow
in their footsteps.  No, not you, but there is a reason why there has
been that push back.

The bigger issue, however, is that there are those who are convinced
that it is a bug that different subsystems have different workflows,
and want to try to converge everyone to A Single Way Of Doing Things.
In some cases, such as trying to define exactly how the Link: or
Change-Id: or what URL to use with the Link: tag, before we even have
had a lot of experience with how things will work.

Others (and I happen to fall in that camp) believe that we should
allow people to experiment, because until we have lived experience
with these different workflows, we won't know how well they work.  If
it is obviously a better way of doing things, then people will adopt
it.  We don't need to legislate rules saying all maintainers must
follow exactly the same workflow, because they may be facing different
set of constraints.

They might not have access to the same continuous testing
infrastructure, especially for subsystems where special hardware is
required.  Or maybe they don't have enough developers and time of
those developers to for group maintainership requiring all patches be
reviewed.  Saying that we're going to force everyone to do things
Exactly The Same Way is not going to end well.

Admittedly, there are some downsides to per-subsystem variations.  It
does make it harder contributors to understand what they need to do in
order to get a patch accepted.  On the other hand, I believe that the
biggest problems in this area is not so much the workflow, but rather
how strict reviewers when they do their review.


For example, consider a new file system used on million devices all
over the world, and which has been consistently getting fix ups and
where the maintainer is very responsive.  What is the threshold before
(a) it gets accepted into staging, (b) it gets accepted as an "all
grown up file system"?  Some people seem to want near perfection
before it should be allowed into the kernel --- and that's why some
file systems have gone into the staging tree.  Some have argued that
file systems should never go through staging, but the reason why they
*do* is because many of these people are those who like to hold new
file systems to super-strict criteria, and others believe that staging
is a better alternative than an out-of-tree file system.

That's a much more profound disagreement than what workflow a
subsystem uses for review and testing, and what the level is of
nit-pickiness that should be used before allowing a commit or a new
subsystem into the tree is not something that can be easily
legislated.

(My opinion is that we are really hazing the prospective maintainer to
make sure they are going to stick around, and that it isn't going to
be a drive by contribution.  I also think we've elevated the criteria
for acceptance much too high, but at least amongst file system
developers, or at least the ones who speak up the most on fsdevel, I
fear I am in the minority.)

					- Ted