[LSF/MM TOPIC] MM maintenance process

[Michal Hocko <mhocko@kernel.org>]

Hi,
I have started this topic last year already but I think we should get
back to it.

Basically I would like to talk about the future of the MM subsystem
maintenance process. I feel we should be following other
subsystems by having multi-maintainers hierarchical model. The amount
of changes is not decreasing, quite contrary, and that puts a lot of
pressure on Andrew.

Last year I have presented that around half of MM changes are not
reviewed properly and that is simply not acceptable for the core
subsystem IMHO. Numbers haven't changed much since then I am afraid.
We have roughly 200 commits each major release which is a lot!
$ git rev-list v4.11..v4.15-rc9 -- mm/ | wc -l
808
$ git rev-list v4.11..v4.15-rc9 -- mm/ | xargs git-grep-changelog.sh "Acked-by:\|Reviewed-by:" | wc -l
439
so only ~55% gets an active review. Please note that these are only
rough numbers because not all of those are s-o-b Andrew. This also only
considers mm/ directory, while there are other MM parts outside (arch
code etc.). By no means I do not want to blame Andrew here.

Where do I see problems?
* most people are busy to do review. I _think_ that having more explicit
  maintainers for MM parts would help with the "responsibility for the
  code".  People do care more when they are officially responsible for
  the code. It wouldn't be all on Andrew's shoulders.
* It is quite hard for non-regular developers to get how the MM subsystem
  works because it is so much different from other subystems. There
  is no standard git tree to develop agains (except for linux-next
  which is not ideal for long term developing).  I've been maintaining
  non-rebased mmotm git tree and Johannes does reconstruct each mmomt
  into git from scratch but not all people know about that and this is
  more of a workaround than a real solution
* mmotm process with early merging strategy and many fixups is not really
  ideal IMHO. Andrew is good in tracking those changes but my experience
  is that it encourages half baked work to be posted and then fixed
  up later. It is also quite hard to keep mental model of the series
  after multiple fixups.
* MM is a core kernel subsystem and relying on the single maintainer
  is hardly sustainable long term. 200 patches/release is a lot!
  We should share the responsibility.
* linux-next is quite a pain to work with due to constant rebases and
  non-stable sha1. I cannot count how many times I had to note that
  Fixes: $sha1 is not valid for mmotm patches.

What I would like to see and propose?
* tip like multi-maintainer git model, where Andrew doesn't have to
  care about each and every patch and rather rely on sub-maintainers.
  Andrew said he highly relies on people anyway. Doing the above would
  save him from a lot of paper work and email traffic.
* we _really_ need much more high level review. I think Andrew is really
  good at that. Giving him more time by reducing the email/patch flow at
  him sounds like a reasonable step to get there.

I suspect all this is for longer discussion so I would propose to give
it 40min - 60min slot.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>