On 12/22/2015 09:27 PM, gre...@linuxfoundation.org wrote: > On Tue, Dec 22, 2015 at 02:15:08PM -0500, ira.weiny wrote: >> On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote: >>> On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote: >>>> 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? >>> >>> 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...
I'm not worried about that. Patchworks makes the workflow reasonable. -- Doug Ledford <dledf...@redhat.com> GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel