Memory-management subsystem workflow
Andrew started off by saying that he does not actually do that much of the
work; he relies heavily on the other memory-management developers to do
code reviews. He allowed that he ignores acks from some developers while
respecting others. He apologized for the "peculiar management" of the
![[Andrew Morton]](https://static.lwn.net/images/conf/2016/lsfmm/AndrewMorton-sm.jpg "Andrew Morton")
-mm tree (but didn't say anything about making changes to how it
is managed). Were there any changes that the other developers would like
to see?
Michal Hocko asked for the inclusion of message IDs in patches to make it easier to figure out where they came from. That can be especially hard when batches of fixes are merged together. Andrew agreed to do this.
With regard to code review, he requested that developers let him know if they don't have time to review patches of interest to them at the moment. He is happy, he said, to "park" the patches until time for reviewing becomes available.
Matthew Wilcox asked Andrew if he would rather, when patches are updated, see incremental fixes or entirely new patch sets. Andrew replied that he would rather see the fixes separately; that allows reviewers to easily see what has changed. But, he said, developers should send whatever seems easiest to review in general; he can always generate a delta from one patch set to the next.
Mel Gorman asked for a more clear distinction between patches that have gone into -mm because they are intended for merging soon and those that are just there for testing. He mentioned, in particular, the team pages patches (discussed the previous day) which, he said, created conflicts with other near-term work. In this case, though, it turns out that Andrew had indeed expected to merge those patches in the 4.7 merge window — a plan which had been changed in the previous day's discussion.
Kirill Shutemov complained that it can be hard to get memory-management patches reviewed sometimes. He wondered if he should be dividing his work into smaller batches, since big patch sets can be scary. Andrew suggest he should "bribe people" to review his work, but acknowledged that he didn't have any better answers for what is a hard and persistent problem. Michal said that he sometimes holds off on posting reviews if he doesn't like a particular patch but lacks ideas for a better solution. Hugh Dickins added that, if he comments on a patch, he ends up on the CC list for subsequent versions. So he is tempted to hold back on reviews in order to keep his email load under control.
At the end of the session, Michal pointed out the large volume of
non-memory-management work that goes through the -mm tree and
asked if that should change. Andrew remains the maintainer of last resort
for much of the kernel. He replied, though, that carrying those other
patches is not a large amount of work, so he sees no strong need to change
things.
| Index entries for this article | |
|---|---|
| Conference | Storage, Filesystem, and Memory-Management Summit/2016 |