-mm tree management
	Andrew Morton <akpm@osdl.org>
	17 Jan 2006

So you just got one of those "patch foo.patch was added to -mm" emails.  Read
on..

If you are the bug reporter:

  Please test the patch.  If it doesn't fix the bug, please let all
  recipients of this email know.

For code maintainers, things aren't as simple.  Generally my processes are
designed to make things as easy as possible for maintainers and for git tree
owners.  I consider both mainline and the git trees to be "upstream".  If a
patch which was in -mm goes into a git tree I'll drop it and forget about it,
under the assumption that the git tree owner will take care of getting the
patch into Linus's tree.


  Review and test the patch!  If it is unacceptable or needs changes, please
  do a reply-to-all and we'll take it from there.

  You don't have to apply the patch to your git tree immediately.  If you
  think it needs more testing in -mm or a bit more work or if you're busy on
  something else, then just duck the email.  It'll come back to you again
  later.  (And again and again).


A developer has several options when an acceptable-looking patch is added to
-mm.

a) If you're a git tree owner, just merge the patch.  I'll drop it when I
   see you've merged it.  No followup email is needed.

b) If you can't be bothered, just ask me to merge it into Linus's tree.

   If you do neither a) nor b), the patch will hang around and I'll resend
   later.

c) If you're a developer whose code goes into Linus's tree via a git tree,
   but you don't control that git tree then you can either

   - Ask me to merge it into Linus's tree (cc the git tree owner).  I'll
     treat this as an Acked-by:.

   - Send the patch on to the tree maintainer yourself

   - Ask me to send it on to the subsystem maintainer.  I'll treat this
     as an Acked-by: too.   If he loses the patch I'll keep resending.


General rule: if you're auto-cc'ed on an added-to-mm email, you don't have to
do anything much right now unless you really want to.  But if I explicitly
send a patch to you then I do hope that you'll do something dispositive with
it promptly.   But please do review the patch as I add it.

Note1: If a patch in -mm is against a subsystem which has a git tree owner, I
will not send the patch to Linus, except under unusual circumstances (patch is
utterly trivial, or very critical and yet obvious, or maintainer is offline).

Note2: I'll usually add a Cc: to the maintainer and/or git tree owner when
adding a patch to -mm, and all the above applies.

But sometimes I won't, because I don't want the patch merged upstream yet. 
It's speculative, or its silly, or I know it needs more work or I am waiting
on review feedback, or testing feedback or whatever.

In this case I'll explicitly send the patch to the maintainer(s) later.

Note3: Sometimes I need prioritisation help identifying which patches need to
be merged into which upstream kernels.  If there's a patch hanging around in
-mm which you think should be going upstream, please let me know.

Note4: I'll often cc developers on a patch for reviewing purposes rather than
for merging purposes: because I expect they know the affected subsystem, or
because they've worked on it before, etc.  Please do help out here and take a
close look at the patch.