[LSF/MM/BPF TOPIC] MM transition

[Andrew Morton <akpm@linux-foundation.org>]

Hi, all.  Some things I'd like to discuss in the "MM process" slot at
LSFMM.

I wish to start unwinding my MM involvement.  Because I'd like to be
able to retire one day.  And because things feel excessively
concentrated - I'm doing too much stuff, others have valuable views. 
I'm healthy (enough), plenty motivated and my mind is still sharp
(shaddup) but bad things happen to 67 year olds and they can happen
swiftly.

I want this this transition to be gradual, orderly and incremental - no
sudden changes.  Give ourselves about one year to do one thing at a time,
re-evaluate at each step, make alterations if needed, on to the next step.
Of course, we have our ongoing mm/ development work and let's avoid
disrupting that.


The model I wish to move towards is a more conventional top-level
integration tree (working title "mm-next") which pulls together N
component[1] trees.  mm-next is the usual source of our mm->linus
pulls.  mm-next will have a hotfixes branch for that material which
we're fast-tracking upstream.

David Hildenbrand has kindly agreed to set up and operate mm-next and I
hope/expect that David will take a leading role in this transition.  

("mm-next" isn't really an appropriate name, but mm.git is being a
namespace hog - some renaming might be needed)

mm-next will initially contain mm.git and, I hope, any other git trees
we can find.  slab and memblock at least temporarily, if Vlastimil and
Mike are agreeable.  I want other trees in there apart from mm.git so
the tooling, processes etc can be worked out.  An "aggregation" tree
which aggregates a single tree is a bit silly.

Once mm.next is up and operating and the pulls are flowing smoothly, let's
introduce one other tree.  This might be "vma" from that component's
maintainers.  Then another tree and so on.  So mm.git gets smaller and
smaller.

I expect that as the backup catchall, mm.git will always have a
significant amount of material.  It will continue to act as a hosting
service for Maintainers who don't wish to operate their own tree.  MM has
~38 listed M:aintainers; many of these parts are small, with low change
rates and M:aintainers have differing levels of engagement, and that's
fine.  Also, there are parts with no identifiable maintainer, some
maintainers will sometimes be unavailable, etc.  Also those little changes
which nobody feels inclined to look at.  MM will continue to need a team
Mom.

I plan to keep running the mm-nonmm branches.  Kernel-wide team Mom - it's
pretty quiet.  And maybe mm.git if it's small enough, if I'm not getting
in the way and if I can't find a sucker^Wkind person to take it over.

For this discussion and in the upcoming meeting please let's not get too
far down into the weeds of tree structures, workflow, individual's roles,
etc.  At this time let's focus on the final implementation and upon my
plan to get from here to there, then we can discuss details.  David will
be hosting some "transition workgroup" meetings after LSFMM to further
these matters.

Thanks.

[1] Terminology: MM is a subsystem of Linux, so the various MM
    subsystems are really subsubsystems.  Confusing!  I propose that we
    Not Do That, and start referring to the various parts of MM as
    "components".  So mm-next aggregates component trees.