On Tue, Aug 18, 2015 at 08:11:26PM -0700, Doug Ledford wrote: > > > On Aug 18, 2015, at 7:49 PM, Greg KH <greg@xxxxxxxxx> wrote: > > > > On Tue, Aug 18, 2015 at 06:24:40PM -0700, Doug Ledford wrote: > >> > >> > >>> Are > >>> you going to be responsible for all of the patches sent to it and you > >>> just want me to ignore them, or will you send patches to me for me to > >>> apply? > >> > >> I expect the patch load to be significant due to the required TODO > >> item of making it use a transfer engine library. I wouldn’t want to > >> sign you up for that load. If you are OK with me processing the > >> patches, then I’m happy to do so. If you would prefer the other way > >> around, then I’ll defer to your wishes. > > > > What is "significant"? I'm kind of used to handling a lot of patches :) > > I have no doubt of that. > > > How are you going to handle all of the coding style fixups that will end > > up coming in from people? Want me to just let you handle all of them as > > well? If so, please remove me from the MAINTAINERS entry for this > > subdirectory so that I, and the driverdevel mailing list do not get the > > emails. > > > > Otherwise, feel free to just send me patches, I can easily handle them. > > Given the amount of stuff I have on the radar for going through the > staging tree (two deprecated drivers to be removed entirely, plan is > move to staging in 4.3, delete from tree in 4.6, this driver and one > other as-of-yet-to-be-submitted driver to be added to tree, both > drivers have the same major TODO item, which is to be converted to use > a library for their transfer engine, which also requires writing said > library), I’m wondering if it isn’t worthwhile to create a > staging/infiniband directory, remove your name and driverdevel from > the maintainer entry for the directory and redirect it to linux-rdma, > and delete it when this work has passed. That sounds like a good plan to me. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
