[lkml]   [2017]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] rdma: Add Jason as a co-maintainer
On Thu, 2017-11-16 at 13:44 -0700, Jason Gunthorpe wrote:
> index 7f9c4f3fc9419d..d4e621e350f2cf 100644
> @@ -6827,6 +6827,7 @@ F: drivers/ipack/
> M: Doug Ledford <>
> +M: Jason Gunthorpe <>
> L:
> W:
> Q:

Hello Doug and Jason,

Thanks Doug for having added a co-maintainer. Jason, thank you for willing
to be a co-maintainer.

Jason, if you are going to send pull requests to Linus you should be aware
of the following:
* Linus trusts pull requests from a repository more than pull
requests from a repository outside (e.g. github). Any requests
to pull from e.g. github must be PGP-signed.
* If you send an e-mail to Wu Fengguang then he will add a branch from your
repository to his zero-day testing. This is a great way to catch build
failures before linux-next catches these.
* Any patches that will be sent to Linus must have been in the for-next
repository for at least a few days. Requests to add a branch to linux-next
should be sent to Stephen Rothwell with linux-next in Cc.
* Maintainers are expected to keep an eye on merge conflicts and other reports
sent out to the linux-next mailing list
* Rebasing a tree that will be sent to Linus is completely inacceptable. A
quote from Linus: "And in general, you simply should never rebase commits
that have already been publicized." Source: Linus Torvalds, Re: linux-next:
Signed-off-by missing for commit in the drivers-x86 tree, linux-next mailing
list, 2 August 2017 (
* Backmerging (merging a later rc into a maintainer tree) to pull in rc fixes
from other maintainers is considered inacceptable too. If patches from other
maintainers are really needed I think it is acceptable to merge a maintainer
tree into Linus' tree and to apply late rc patches on top of that merged

See also

Best regards,

 \ /
  Last update: 2017-11-17 18:55    [W:0.178 / U:4.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site