On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote: > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote: > > Greg, Doug, > > > > As mentioned below, these patches depend on the new rdmavt library > > submitted to > > Doug on linux-rdma. > > > > We continue to identify (and rework) patches by our other developers which > > can > > be submitted without conflicts with this series. Furthermore, We have, as > > much > > as possible, placed fixes directly into rdmavt such that those changes can > > be > > dropped from hfi1. But at this point, we need to know if and where these > > are > > going to land so that we can start reworking as appropriate. > > > > Therefore, I would like to discuss plans to get hfi1 under the same > > maintainer > > to work through this transitional period. > > > > Basically, At what point should we stop submitting patches to Greg and start > > submitting to Doug? > > > > Should we consider the merge window itself as the swap over point and submit > > changes to Doug at that point? If so, should we continue to submit what we > > can > > to Greg until then (and continue rebase'ing the series below on that work)? > > Or > > given Gregs backlog, should we stop submitting to Greg sometime prior to the > > merge window? > > > > That brings up my final question, at the point of swap over I assume > > anything > > not accepted by Greg should be considered rejected and we need to resubmit > > to > > Doug? > > 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? How do we handle changes which affect both qib and hfi1? Ira > > That's the easiest thing to do usually. > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel