| Message ID | 20171116204400.GA28216@mellanox.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > As was discussed in September and October, add Jason along with > Doug to have a team maintainership model for the RDMA subystem. > > Mellanox Technologies will be funding Jason's independent work on > the maintainership. > > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> > --- > .mailmap | 2 ++ > MAINTAINERS | 1 + > 2 files changed, 3 insertions(+) > > My updated PGP key with the new email addresses is in the key servers > and available here: > > http://www.ziepe.ca/pgp/jgunthorpe.gpg > > diff --git a/.mailmap b/.mailmap > index c021f29779a7a1..1469ff0d3f4d55 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -73,6 +73,8 @@ James E Wilson <wilson@specifix.com> > James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com> > James Hogan <jhogan@kernel.org> <james@albanarts.com> > James Ketrenos <jketreno@io.(none)> > +Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com> > +Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com> > Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com> > <javier@osg.samsung.com> <javier.martinez@collabora.co.uk> > Jean Tourrilhes <jt@hpl.hp.com> > diff --git a/MAINTAINERS b/MAINTAINERS > index 7f9c4f3fc9419d..d4e621e350f2cf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6827,6 +6827,7 @@ F: drivers/ipack/ > > INFINIBAND SUBSYSTEM > M: Doug Ledford <dledford@redhat.com> > +M: Jason Gunthorpe <jgg@mellanox.com> Jason, I want to warn that you will have hard to use your @mellanox.com address for any external to Mellanox communication, because of questionable IT innovation - they rewrite links in all coming emails. It will make your replies looking very bad and it will be unreadable for the people who are using plain text readers to read emails. The example of it, you can see here [1]. We (top Mellanox upstreamers) tried to fight for it for the more than half a year, and gave up - using my external email for everything. Thanks [1] https://marc.info/?l=linux-rdma&m=151077009200628&w=2 > L: linux-rdma@vger.kernel.org > W: http://www.openfabrics.org/ > Q: http://patchwork.kernel.org/project/linux-rdma/list/ > -- > 2.7.4 >
T24gVGh1LCAyMDE3LTExLTE2IGF0IDEzOjQ0IC0wNzAwLCBKYXNvbiBHdW50aG9ycGUgd3JvdGU6 DQo+IGRpZmYgLS1naXQgYS9NQUlOVEFJTkVSUyBiL01BSU5UQUlORVJTDQo+IGluZGV4IDdmOWM0 ZjNmYzk0MTlkLi5kNGU2MjFlMzUwZjJjZiAxMDA2NDQNCj4gLS0tIGEvTUFJTlRBSU5FUlMNCj4g KysrIGIvTUFJTlRBSU5FUlMNCj4gQEAgLTY4MjcsNiArNjgyNyw3IEBAIEY6CWRyaXZlcnMvaXBh Y2svDQo+ICANCj4gIElORklOSUJBTkQgU1VCU1lTVEVNDQo+ICBNOglEb3VnIExlZGZvcmQgPGRs ZWRmb3JkQHJlZGhhdC5jb20+DQo+ICtNOglKYXNvbiBHdW50aG9ycGUgPGpnZ0BtZWxsYW5veC5j b20+DQo+ICBMOglsaW51eC1yZG1hQHZnZXIua2VybmVsLm9yZw0KPiAgVzoJaHR0cDovL3d3dy5v cGVuZmFicmljcy5vcmcvDQo+ICBROglodHRwOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcHJvamVj dC9saW51eC1yZG1hL2xpc3QvDQoNCkhlbGxvIERvdWcgYW5kIEphc29uLA0KDQpUaGFua3MgRG91 ZyBmb3IgaGF2aW5nIGFkZGVkIGEgY28tbWFpbnRhaW5lci4gSmFzb24sIHRoYW5rIHlvdSBmb3Ig d2lsbGluZw0KdG8gYmUgYSBjby1tYWludGFpbmVyLg0KDQpKYXNvbiwgaWYgeW91IGFyZSBnb2lu ZyB0byBzZW5kIHB1bGwgcmVxdWVzdHMgdG8gTGludXMgeW91IHNob3VsZCBiZSBhd2FyZQ0Kb2Yg dGhlIGZvbGxvd2luZzoNCiogTGludXMgdHJ1c3RzIHB1bGwgcmVxdWVzdHMgZnJvbSBhIGtlcm5l bC5vcmcgcmVwb3NpdG9yeSBtb3JlIHRoYW4gcHVsbA0KICByZXF1ZXN0cyBmcm9tIGEgcmVwb3Np dG9yeSBvdXRzaWRlIGtlcm5lbC5vcmcgKGUuZy4gZ2l0aHViKS4gQW55IHJlcXVlc3RzDQogIHRv IHB1bGwgZnJvbSBlLmcuIGdpdGh1YiBtdXN0IGJlIFBHUC1zaWduZWQuDQoqIElmIHlvdSBzZW5k IGFuIGUtbWFpbCB0byBXdSBGZW5nZ3VhbmcgdGhlbiBoZSB3aWxsIGFkZCBhIGJyYW5jaCBmcm9t IHlvdXINCiAgcmVwb3NpdG9yeSB0byBoaXMgemVyby1kYXkgdGVzdGluZy4gVGhpcyBpcyBhIGdy ZWF0IHdheSB0byBjYXRjaCBidWlsZA0KICBmYWlsdXJlcyBiZWZvcmUgbGludXgtbmV4dCBjYXRj aGVzIHRoZXNlLg0KKiBBbnkgcGF0Y2hlcyB0aGF0IHdpbGwgYmUgc2VudCB0byBMaW51cyBtdXN0 IGhhdmUgYmVlbiBpbiB0aGUgZm9yLW5leHQNCiAgcmVwb3NpdG9yeSBmb3IgYXQgbGVhc3QgYSBm ZXcgZGF5cy4gUmVxdWVzdHMgdG8gYWRkIGEgYnJhbmNoIHRvIGxpbnV4LW5leHQNCiAgc2hvdWxk IGJlIHNlbnQgdG8gU3RlcGhlbiBSb3Rod2VsbCB3aXRoIGxpbnV4LW5leHQgaW4gQ2MuDQoqIE1h aW50YWluZXJzIGFyZSBleHBlY3RlZCB0byBrZWVwIGFuIGV5ZSBvbiBtZXJnZSBjb25mbGljdHMg YW5kIG90aGVyIHJlcG9ydHMNCiAgc2VudCBvdXQgdG8gdGhlIGxpbnV4LW5leHQgbWFpbGluZyBs aXN0DQogIChodHRwOi8vdmdlci5rZXJuZWwub3JnL3ZnZXItbGlzdHMuaHRtbCNsaW51eC1uZXh0 KS4NCiogUmViYXNpbmcgYSB0cmVlIHRoYXQgd2lsbCBiZSBzZW50IHRvIExpbnVzIGlzIGNvbXBs ZXRlbHkgaW5hY2NlcHRhYmxlLiBBDQogIHF1b3RlIGZyb20gTGludXM6ICJBbmQgaW4gZ2VuZXJh bCwgeW91IHNpbXBseSBzaG91bGQgbmV2ZXIgcmViYXNlIGNvbW1pdHMNCiAgdGhhdCBoYXZlIGFs cmVhZHkgYmVlbiBwdWJsaWNpemVkLiIgU291cmNlOiBMaW51cyBUb3J2YWxkcywgUmU6IGxpbnV4 LW5leHQ6DQogIFNpZ25lZC1vZmYtYnkgbWlzc2luZyBmb3IgY29tbWl0IGluIHRoZSBkcml2ZXJz LXg4NiB0cmVlLCBsaW51eC1uZXh0IG1haWxpbmcNCiAgbGlzdCwgMiBBdWd1c3QgMjAxNyAoaHR0 cHM6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMva2VybmVsL21zZzI1NzE1ODQuaHRtbCkuDQoqIEJh Y2ttZXJnaW5nIChtZXJnaW5nIGEgbGF0ZXIgcmMgaW50byBhIG1haW50YWluZXIgdHJlZSkgdG8g cHVsbCBpbiByYyBmaXhlcw0KICBmcm9tIG90aGVyIG1haW50YWluZXJzIGlzIGNvbnNpZGVyZWQg aW5hY2NlcHRhYmxlIHRvby4gSWYgcGF0Y2hlcyBmcm9tIG90aGVyDQogIG1haW50YWluZXJzIGFy ZSByZWFsbHkgbmVlZGVkIEkgdGhpbmsgaXQgaXMgYWNjZXB0YWJsZSB0byBtZXJnZSBhIG1haW50 YWluZXINCiAgdHJlZSBpbnRvIExpbnVzJyB0cmVlIGFuZCB0byBhcHBseSBsYXRlIHJjIHBhdGNo ZXMgb24gdG9wIG9mIHRoYXQgbWVyZ2VkDQogIHRyZWUuDQoNClNlZSBhbHNvIGh0dHBzOi8vbHdu Lm5ldC9BcnRpY2xlcy8zMjg0MzYvLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkJhcnQu -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 17, 2017 at 05:54:34PM +0000, Bart Van Assche wrote: > Thanks Doug for having added a co-maintainer. Jason, thank you for willing > to be a co-maintainer. Thank you Bart! > Jason, if you are going to send pull requests to Linus you should be aware > of the following: I think we will work up to that, obviously I will be working with Doug and his expertise and experience will guide what happens. A new git tree has been setup for RDMA: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/ This will replace Doug's personal k.o tree effective immediately as the cannonical source for the RDMA work in progress. Both Doug and I have write privileges to this tree. > * Linus trusts pull requests from a kernel.org repository more than pull > requests from a repository outside kernel.org (e.g. github). Any requests > to pull from e.g. github must be PGP-signed. Done > * 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. Thanks > * 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. Doug will send Stephen Rothwell a note to move his for-next pull for RDMA from Doug's personal directory to: git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git Branch k.o/for-next > * Maintainers are expected to keep an eye on merge conflicts and other reports > sent out to the linux-next mailing list > (http://vger.kernel.org/vger-lists.html#linux-next). Good advice.. > * 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 (https://www.spinics.net/lists/kernel/msg2571584.html). Yes, of course > * 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 > tree. Yes, this gets tricky if two trees have to coordinate.. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2017-11-17 at 11:14 -0700, Jason Gunthorpe wrote: > On Fri, Nov 17, 2017 at 05:54:34PM +0000, Bart Van Assche wrote: > > > > * 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. > > Thanks On that point...I have my github repo tied into the 0day infrastructure, not the official repo. I do that because I've publicly announced that my github repo is a WIP repo, and that it might be rebased. That allows me to correct build issues by fixing up the broken patch and thereby keep bisectability at its highest. If you use a branch/tag on k.o for your 0day testing, then fixes have to be incremental and depending on which patch broke the build, there might be a significant segment of code that is no longer bisectable. > > * 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. > > Doug will send Stephen Rothwell a note to move his for-next pull for > RDMA from Doug's personal directory to: > > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git > > Branch k.o/for-next Actually, the linux-next testing uses a tag instead of a branch. That allows for oddball scenarios that you might want to get testing. Say, for instance, that you have a for-next branch with most of your stuff, but you also have a separate branch that simply isn't ready to be pushed yet, but you still want to get some early merge analysis, then you create a throwaway branch, merge your for-next and this topic branch together, throw the for-next tag on it for a couple or three days, and if Stephen doesn't find anything, you're on the right path with your development code. Then you just reset the tag prior to pushing to Linus.
On Fri, Nov 17, 2017 at 02:45:01PM -0500, Doug Ledford wrote: > On that point...I have my github repo tied into the 0day infrastructure, > not the official repo. I do that because I've publicly announced that > my github repo is a WIP repo, and that it might be rebased. That allows > me to correct build issues by fixing up the broken patch and thereby > keep bisectability at its highest. If you use a branch/tag on k.o for > your 0day testing, then fixes have to be incremental and depending on > which patch broke the build, there might be a significant segment of > code that is no longer bisectable. .. and this is because the k.o repo is setup to disallow force push for each branch, so a 0 day testing branch cannot be rebased? > > Doug will send Stephen Rothwell a note to move his for-next pull for > > RDMA from Doug's personal directory to: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git > > > > Branch k.o/for-next > > Actually, the linux-next testing uses a tag instead of a branch. That > allows for oddball scenarios that you might want to get testing. Say, > for instance, that you have a for-next branch with most of your stuff, > but you also have a separate branch that simply isn't ready to be pushed > yet, but you still want to get some early merge analysis, then you > create a throwaway branch, merge your for-next and this topic branch > together, throw the for-next tag on it for a couple or three days, and > if Stephen doesn't find anything, you're on the right path with your > development code. Then you just reset the tag prior to pushing to > Linus. Makes sense, this is why I said you'll send the note, because you know how it is setup :) Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2017-11-17 at 14:32 -0700, Jason Gunthorpe wrote: > On Fri, Nov 17, 2017 at 02:45:01PM -0500, Doug Ledford wrote: > > > On that point...I have my github repo tied into the 0day infrastructure, > > not the official repo. I do that because I've publicly announced that > > my github repo is a WIP repo, and that it might be rebased. That allows > > me to correct build issues by fixing up the broken patch and thereby > > keep bisectability at its highest. If you use a branch/tag on k.o for > > your 0day testing, then fixes have to be incremental and depending on > > which patch broke the build, there might be a significant segment of > > code that is no longer bisectable. > > .. and this is because the k.o repo is setup to disallow force push > for each branch, so a 0 day testing branch cannot be rebased? Well, there are ways around the system if you really wanted to do so. You can push to k.o with an empty ref, aka something like 'git push k.o :k.o/for-next', which will delete the old branch. Then you could rebase it locally and repush it. But that would make you a very evil person and if Linus found out he would (rightfully!) yell at you for many paragraphs with lots of all caps ;-). The other option is to delete the bad branch and push a new branch with a different name and the rebase already done. I did that a couple times in the early days of this job. Now a days, I wouldn't even do this for anything short of a disk corrupting issue or something like that. I've come to appreciate just how much people rely on unchanging commit IDs. So the fact that the k.o repos don't allow non-fast-forward pushes is an inconvenience, but it doesn't stop you from doing it if you really wanted to. But it's very bad form to do so, and that's the real reason that I keep my 0day source on github and tell people regularly that my github repo is a "rebase allowed" repo. So, my workflow in order to prevent getting a bad branch on k.o goes something like this: 1) Bundle up patches that belong together as a bundle in patchworks 2) Review patches 3) Download bundle from patchworks, apply using git -am. Do any edits to commit messages at this stage, either by hand editing the bundle file before you run git -am, or afterwards by doing a git rebase -i. 4) Build locally and frequently as you take stuff in. I suggest a build between each bundle. It's much easier to fix up errors when they aren't buried 40 patches deep in your day's work. I use partial builds for the intermediate builds (make SUBDIRS=drivers/infiniband usually, but other directories if the bundle touched code elsewhere). 5) When I think I'm basically done for the day, then I do a final, full kernel build. 6) Push to 0day repo, wait for results. This is a good time to do whatever run testing you plan on doing for this push. 7) Push to k.o once 0day and your testing has passed. Following that workflow minimizes the chances of having a broken push to k.o. If something does actually slip through this workflow, then you just fix it incrementally unless leaving the issue will cause a meltdown of the Internet or something. The one thing it doesn't catch, which is actually what caused the time or two I had to delete a branch and make a new branch on k.o, is when you have to manually apply a patch because git am said the patch didn't apply cleanly. Most times, just running patch -p1 -l < .git/rebase-apply/patch gets the patch in. Git am will reject patches for any fuzz. If we were using git merge/pull, there is often enough context for git to know when to allow the fuzz, but the am mode of git doesn't have that info and dumps on very minor issues. So you manually apply the patch, accepting some fuzz, and inspect the result. Where I screwed up in the past, is when the patch adds a totally new file to the repo. My usual workflow after applying the patch manually, and then inspecting any suspect areas and hand editing files when hunks get rejected, is to run git add -u. This fails to add new files to the commit. So, I had to add an additional git status step to see if there are any new, untracked files before I run the final git am --continue. If you split step 5 above into 5a) Push from local work repo to local prep repo and 5b) Do full kernel build in prep repo to test that all code needed to compile is tracked by git, it would catch that mistake before it makes it outside the firewall. That's a change I may make just to be on the safe side in the future.
On Fri, Nov 17, 2017 at 08:44:27PM -0500, Doug Ledford wrote: > > If you split step 5 above into 5a) Push from local work repo to local > prep repo and 5b) Do full kernel build in prep repo to test that all > code needed to compile is tracked by git, it would catch that mistake > before it makes it outside the firewall. That's a change I may make > just to be on the safe side in the future. I'm using git worktree command [1] for that. If it helps, this is snippet from my scripts: ----------------------------------------- REPORT_FILE=$(mktemp) function do_one { SHA1=$1 REPORT_FILE=$2 PDIR=$(mktemp -d) git worktree add $PDIR $SHA1 echo "Redirecting the output to $REPORT_FILE" pushd $PDIR &>> $REPORT_FILE x checkpatch HEAD $PDIR &>> $REPORT_FILE cp $KCONFIG . &>> $REPORT_FILE make olddefconfig &>> $REPORT_FILE echo "===== FULL COMPILE =========" &>> $REPORT_FILE make -s -j 4 &>> $REPORT_FILE echo "===== SUB COMPILE =========" &>> $REPORT_FILE make -s -j 4 W=1 drivers/infiniband/ drivers/net/ethernet/mellanox/ &>> $REPORT_FILE echo "===== SMATCH =========" &>> $REPORT_FILE make CHECK="$SMATCH -p=kernel" C=1 drivers/infiniband/ drivers/net/ethernet/mellanox/ -s -j 4 &>> $REPORT_FILE echo "===== SPARSE =========" &>> $REPORT_FILE make CHECK="$SPARSE" C=2 drivers/infiniband/ drivers/net/ethernet/mellanox/ -s -j 4 &>> $REPORT_FILE popd &>> $REPORT_FILE rm -rf $PDIR git worktree prune # TODO: separate checkpatch errors, sparse, smatch NUMB_OF_ERRORS=$(awk -F": " '{print $1}' $REPORT_FILE | grep ":" | sort | uniq |wc -l) echo "There are $NUMB_OF_ERRORS errors/warnings" } do_one $SHA1 $REPORT_FILE ------------------------------------------ Thanks [1] https://git-scm.com/docs/git-worktree > > -- > Doug Ledford <dledford@redhat.com> > GPG KeyID: B826A3330E572FDD > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
> Hello Doug and Jason, > > Thanks Doug for having added a co-maintainer. Jason, thank you for willing > to be a co-maintainer. > <snip> > Best regards, > > Bart.N I echo that, thank you both! Ram
Jason, > As was discussed in September and October, add Jason along with > Doug to have a team maintainership model for the RDMA subystem. Happy to see this happening, thanks for stepping up. Thanks to everyone who allowed it to happen (especially Doug). Good Luck! -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > As was discussed in September and October, add Jason along with > Doug to have a team maintainership model for the RDMA subystem. > > Mellanox Technologies will be funding Jason's independent work on > the maintainership. > > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> > --- > .mailmap | 2 ++ > MAINTAINERS | 1 + > 2 files changed, 3 insertions(+) > Doug and Jason, Can you forward the current fixes to Linus? I have more fixes from Parav and fix to iWARP from Daniel, but I prefer to have proper RDMA branches before I'm posting them. Thanks
On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote: > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > > As was discussed in September and October, add Jason along with > > Doug to have a team maintainership model for the RDMA subystem. > > > > Mellanox Technologies will be funding Jason's independent work on > > the maintainership. > > > > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> > > .mailmap | 2 ++ > > MAINTAINERS | 1 + > > 2 files changed, 3 insertions(+) > > > > Doug and Jason, > > Can you forward the current fixes to Linus? > > I have more fixes from Parav and fix to iWARP from Daniel, but I prefer > to have proper RDMA branches before I'm posting them. I belive Doug has already sent the pull request for this merge window, and the new shared tree location is fully up to date, and there are no accepted but unset patches at this time? Do you see otherwise? We are now doing patches for rc. The iWarp security fix from Daniel is definitely rc material. Can you split that 33 patch series into things you think are rc material? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 20, 2017 at 11:06:31AM -0700, Jason Gunthorpe wrote: > On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote: > > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > > > As was discussed in September and October, add Jason along with > > > Doug to have a team maintainership model for the RDMA subystem. > > > > > > Mellanox Technologies will be funding Jason's independent work on > > > the maintainership. > > > > > > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> > > > .mailmap | 2 ++ > > > MAINTAINERS | 1 + > > > 2 files changed, 3 insertions(+) > > > > > > > Doug and Jason, > > > > Can you forward the current fixes to Linus? > > > > I have more fixes from Parav and fix to iWARP from Daniel, but I prefer > > to have proper RDMA branches before I'm posting them. > > I belive Doug has already sent the pull request for this merge window, > and the new shared tree location is fully up to date, and there are > no accepted but unset patches at this time? I still see for-rc points to old (4.14) code. https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=k.o/for-rc There is a need to advance -rc to be equal to -next during merge window, so we will be able to actually base our -rc/-next patches. > > Do you see otherwise? > > We are now doing patches for rc. > > The iWarp security fix from Daniel is definitely rc material. There is no need to wait for -rc1 to send bug fixes and Linus accepts and welcomes bug fixes during merge window, see the pull requests from Dave and others. > > Can you split that 33 patch series into things you think are rc > material? I'll take a look, but most probably I'll skip the split exercise. This patch set was tested as one series and separation will require two addition passes for the verification: one for-rc and another for for-next. Thanks > > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 21, 2017 at 07:04:56AM +0200, Leon Romanovsky wrote: > On Mon, Nov 20, 2017 at 11:06:31AM -0700, Jason Gunthorpe wrote: > > On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote: > > > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > > > > As was discussed in September and October, add Jason along with > > > > Doug to have a team maintainership model for the RDMA subystem. > > > > > > > > Mellanox Technologies will be funding Jason's independent work on > > > > the maintainership. > > > > > > > > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> > > > > .mailmap | 2 ++ > > > > MAINTAINERS | 1 + > > > > 2 files changed, 3 insertions(+) > > > > > > > > > > Doug and Jason, > > > > > > Can you forward the current fixes to Linus? > > > > > > I have more fixes from Parav and fix to iWARP from Daniel, but I prefer > > > to have proper RDMA branches before I'm posting them. > > > > I belive Doug has already sent the pull request for this merge window, > > and the new shared tree location is fully up to date, and there are > > no accepted but unset patches at this time? > > I still see for-rc points to old (4.14) code. > https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=k.o/for-rc > > There is a need to advance -rc to be equal to -next during merge window, > so we will be able to actually base our -rc/-next patches. And for-next misses one patch, which I sent directly to Linus https://patchwork.kernel.org/patch/10032391/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/infiniband/core/nldev.c?id=287683d027a3ff83feb6c7044430c79881664ecf https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=k.o/for-next Thanks
diff --git a/.mailmap b/.mailmap index c021f29779a7a1..1469ff0d3f4d55 100644 --- a/.mailmap +++ b/.mailmap @@ -73,6 +73,8 @@ James E Wilson <wilson@specifix.com> James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com> James Hogan <jhogan@kernel.org> <james@albanarts.com> James Ketrenos <jketreno@io.(none)> +Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com> +Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com> Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com> <javier@osg.samsung.com> <javier.martinez@collabora.co.uk> Jean Tourrilhes <jt@hpl.hp.com> diff --git a/MAINTAINERS b/MAINTAINERS index 7f9c4f3fc9419d..d4e621e350f2cf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6827,6 +6827,7 @@ F: drivers/ipack/ INFINIBAND SUBSYSTEM M: Doug Ledford <dledford@redhat.com> +M: Jason Gunthorpe <jgg@mellanox.com> L: linux-rdma@vger.kernel.org W: http://www.openfabrics.org/ Q: http://patchwork.kernel.org/project/linux-rdma/list/
As was discussed in September and October, add Jason along with Doug to have a team maintainership model for the RDMA subystem. Mellanox Technologies will be funding Jason's independent work on the maintainership. Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> --- .mailmap | 2 ++ MAINTAINERS | 1 + 2 files changed, 3 insertions(+) My updated PGP key with the new email addresses is in the key servers and available here: http://www.ziepe.ca/pgp/jgunthorpe.gpg