> > > > > > > > > > If Doug accepts the library changes, let me know that public git commit > > > > > and I can pull it into the staging-next branch and you can continue to > > > > > send me staging patches that way. > > > > > > > > Won't this cause a conflict during the merge window? > > > > > > No, git is good :) > > > > > > > How do we handle changes which affect both qib and hfi1? > > > > > > I don't know, now this gets messy... > > > > > > > Agreed and this is what we are worried about. > > > > Can we do what Dan and Doug have proposed in the past and have Doug take over > > the staging/rdma sub-tree? > > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html > > > > I think the upcoming merge window is a reasonable time for him to do that. > > Ok, but keeping on top of all of the generic staging patches that come > in is a tough thing to do, that's up to Doug, if he is ready for it... > Greg, Forgive me for not knowing how multiple maintainers deal with hand offs like this. I'm hoping you, and/or Doug, can answer some questions for me. Am I correct in assuming the merge window will be open on Monday? If so, when will Linus pull the staging tree? Then at what point will Doug get the hfi1 changes which have already been accepted? Are you going to be able to review the outstanding patches for staging/rdma/hfi1 before the merge window? Or should we consider them dropped and resubmit to Doug to apply after he has merged the latest hfi1 code from Linus? Doug, At what point should we start submitting additional patches to you which we have queued up but are not yet submitted to Greg? So far we have been cross posting to linux-rdma for feedback and I see that the patches have been dropped from patchworks. I assume you dropped them from patchworks because you knew that Greg was handling them? Thanks, Ira _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
