[LSF/MM TOPIC] mm patches review bandwidth

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
I have a very bad feeling that we are running out of the patch review
bandwidth for quite some time. Quite often it is really hard to get
any feedback at all. This leaves Andrew in an unfortunate position when
he is pushed to merge changes which are not reviewed.

A quick check shows that around 40% of patches is not tagged with
neither Acked-by nor Reviewed-by. While this is not any hard number it
should give us at least some idea...

$ git rev-list --no-merges v4.8..v4.9 -- mm/ | wc -l 
150
$ git rev-list --no-merges v4.8..v4.9 -- mm/ | while read sha1; do git show $sha1 | grep "Acked-by\|Reviewed-by" >/dev/null&& echo $sha1; done | wc -l
87

The overall trend since 4.0 shows that this is quite a consistent number

123 commits in 4.0..4.1 range 47 % unreviewed
170 commits in 4.1..4.2 range 56 % unreviewed
187 commits in 4.2..4.3 range 35 % unreviewed
176 commits in 4.3..4.4 range 34 % unreviewed
220 commits in 4.4..4.5 range 32 % unreviewed
199 commits in 4.5..4.6 range 42 % unreviewed
217 commits in 4.6..4.7 range 41 % unreviewed
247 commits in 4.7..4.8 range 39 % unreviewed
150 commits in 4.8..4.9 range 42 % unreviewed

I am worried that the number of patches posted to linux-mm grows over
time while the number of reviewers doesn't scale up with that trend. I
believe we need to do something about that and aim to increase both the
number of reviewers as well as the number of patches which are really
reviewed. I am not really sure how to achieve that, though. Requiring
Acked-by resp. Reviewed-by on each patch sounds like the right approach
but I am just worried that even useful changes could get stuck without
any forward progress that way.

Another problem, somehow related, is that there are areas which have
evolved into a really bad shape because nobody has really payed
attention to them from the architectural POV when they were merged. To
name one the memory hotplug doesn't seem very healthy, full of kludges,
random hacks and fixes for fixes working for a particualr usecase
without any longterm vision. We have allowed to (ab)use concepts like
ZONE_MOVABLE which are finding new users because that seems to be the
simplest way forward. Now we are left with fixing the code which has
some fundamental issues because it is used out there. Are we going to do
anything about those? E.g. generate a list of them, discuss how to make
that code healthy again and do not allow new features until we sort that
out?
-- 
Michal Hocko
SUSE Labs

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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]