[Ksummit-discuss] [MAINTAINERS SUMMIT] Developing across multiple areas of the kernel

[James Bottomley]

On Fri, 2017-07-14 at 18:35 +0300, Leon Romanovsky wrote:
> On Fri, Jul 14, 2017 at 04:10:57PM +0200, Andrew Lunn wrote:
> > 
> > > 
> > > The difference in maintainers style between netdev and RDMA
> > > causes to have long queue
> > > (100+) of patches posted to the ML [2], which are not cross-
> > > checked in various CIs.
> > 
> > It is possible to get 0-day to run against any arbitrary git tree,
> > if you ask nicely. If same is true for the kernel-ci project. So if
> > you are willing to do the merge work, you can get it tested.
> 
> 0-day is checking my tree, so it is not the problem.
> 
> I don't see how kernel-ci can help me, because RDMA requires special
> hardware to run it and it usually requires more than two endpoints
> (servers) connected together.
> 
> My problem is related to changes in other trees for example netdev,
> which can break RDMA functionality.
> 
> Technology wise, there are:
> 1. RoCE - RDMA over Converged Ethernet - netdev is below RDMA
> 2. IPoIB - IP over Infiniband - netdev is above RDMA
> 3. HFI-VNIC - Ethernet over OmniPath - netdev is above RDMA
> 4. iWARP - RDMA over IP networks
> e.t.c.

So I think your goal is to get your tree and the one above you (Doug's
tree) into linux-next without causing a mismerge nightmare?

I still didn't get why you can't change workflow to share commits? If
you can do that, linux-next can be based on both your tree and the one
above it. You can do this either by you sending pull requests or by you
basing on the upstream tree and rebasing when the patches are accepted
(rebase is very good at recognizing and discarding the same patch with
a different commit id).

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20170714/64178e92/attachment.sig>