From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from opengridcomputing.com ([70.118.0.34]:52350 "EHLO smtp.opengridcomputing.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S969480AbeCSTu5 (ORCPT ); Mon, 19 Mar 2018 15:50:57 -0400 Subject: Re: interdependencies with cxgb4 and iw_cxgb4 To: David Miller Cc: rajur@chelsio.com, dledford@redhat.com, linux-rdma@vger.kernel.org, jgg@ziepe.ca, netdev@vger.kernel.org, bharat@chelsio.com, ganeshgr@chelsio.com, rahul.lakkireddy@chelsio.com References: <022f01d3bba9$82e94870$88bbd950$@opengridcomputing.com> <20180316.122150.516267509367905206.davem@davemloft.net> From: Steve Wise Message-ID: <2cbb87bf-9020-2788-be75-1dd7f48f6c42@opengridcomputing.com> Date: Mon, 19 Mar 2018 14:50:57 -0500 MIME-Version: 1.0 In-Reply-To: <20180316.122150.516267509367905206.davem@davemloft.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 3/16/2018 11:21 AM, David Miller wrote: > From: "Steve Wise" > Date: Wed, 14 Mar 2018 10:31:24 -0500 > >> This issue has also been dealt-with for Mellanox drivers, I believe. I take >> it the solution for them was a k.o. signed repo, that they maintain, where >> both linux-rdma and netdev take PRs from for commits that are needed in both >> repos. Then these are reconciled when both repos are merged into Linus' >> repo. (I hope my understanding of this is correct) >> >> For Chelsio, this is perhaps a possibility, but I'm wondering if there is a >> simpler solution? A few other option we've been discussing include: >> >> 1) submit the cxgb4-only changes to netdev in release cycle X, and then only >> submit the iw_cxgb4 (or other upper drivers) changes that use them in >> release cycle X+1. The pro of this is simplicity. The con is timeliness - >> it takes 2 release cycles to get the feature upstream. >> >> 2) run the entire series through one maintainer's repo (with all >> maintainers' ACK on the content and plan, of course), and ensuring no >> conflicting commits are submitted for the rest of that release cycle. I'm >> not really sure that this is feasible given anyone could create commits for >> upstream drivers. So how could Chelsio really control this? >> >> Do you have any suggestions on how we should proceed? > I think the Mellanox setup is working well currently. > > If the changes get pulled into both the rdma and networking tree, then it > all gets resolved cleanly no matter which of rdma or networking goes into > Linus's tree first during the merge window. > > It doesn't have the delay issues of suggestion #1, and I think avoiding > conflicts in situation #2 is next to impossible. > > In fact, such conflict problems are how we arrived at the approach > Mellanox is using in the first place. > Thanks Dave. Let me ask a dumb question:  Why cannot one of the maintaners pull the commit from the other mainainer's git repo directly?  IE why have this third trusted/signed git repo that has to be on k.o, from which both maintainers pull?  If one of you can pull it in via a patch series, like you do for all other patches, and then notify the other maintainer to pull it from the first maintainers' repo if the series meets the requirements that it needs to be in both maintainers' repositories?  This avoids adding more staging git repos on k.o.  But probably I'm missing something... Steve.