Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2017-04-20 at 08:47 -0600, Jonathan Corbet wrote:
> On Thu, 20 Apr 2017 06:33:58 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > I think it's worth discussing this.  We accept a lot of patches 
> > because we can and because the change looks innocuous enough, but 
> > which don't actually have a tangible user visible benefit.  Should 
> > we actually have a net benefit threshold test we apply?
> 
> With regard to the documentation patches, the intended tangible
> user-visible benefit is to turn a jumbled mess of a documentation
> directory into a set of coherent manuals that are aimed at and 
> readily accessible to our different audiences (kernel developers, 
> system administrators, application developers, etc. as appropriate).

I'm not saying don't do it, I'm staying understand the cost vs benefit
before doing it.

> If we had always tossed the SCSI subsystem source into a single
> directory along with SCTP, user-mode Linux, perf, half of the TTY
> drivers, and all filesystems written before the second Bush
> administration, it would certainly make for easier muscle-memory
> access for those of us who think back nostalgically to installing
> from floppies.  But for some strange reason we don't do that.

I'm also not saying do a flat tree.  I am saying putting things in the
right place ab initio and then having a reasonably high barrier for
moving it has value.

> When code needs refactoring, we do so - when, as you said, there is a
> tangible benefit.

Right, I think we've been quite good at the refactor net benefit tests
... mostly, I think, because refactoring is a lot of work and a lot of
argument to get it accepted so people think very carefully before they
do it.  It is self supplying on the net benefit test ... I think we
have certain actions which aren't so self supplying in this regard.

Ideally, everything would be like this: the level of difficulty in
doing something would be directly proportional to the amount of thought
you should put into it.  However, the world is not mostly structured
like this hence the question about a net benefit test which would raise
the barrier.

>   The same applies to directory organization.  Though that may not
> apply to Documentation/ since we never really got around
> to an original factoring to refactor.
> 
> Anyway, you can see why I raised the issue.  I think that this 
> process is improving the documentation, making it more accessible, 
> and making more people interested in improving it.  But I have my 
> hands plenty full of other things and, if this work is really 
> swimming against the current, it would be good to know.

I'd prefer it if the summit didn't become a star chamber where we re
-run past decisions.  However, I think the process question of how (or
whether) we should add process barriers for certain actions is a useful
one.

James