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

[Leon Romanovsky <leon@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]

On Fri, Jul 14, 2017 at 11:54:09AM +0200, Greg KH wrote:
> On Fri, Jul 14, 2017 at 07:04:47AM +0300, Leon Romanovsky wrote:
> > On Fri, Jun 30, 2017 at 06:27:17AM +1000, Stephen Rothwell wrote:
> > > Hi Kees,
> > >
> > > On Thu, 29 Jun 2017 13:16:40 -0700 Kees Cook <keescook@chromium.org> wrote:
> > > >
> > > > [1] If the solution for this is to merge other -next trees into mine,
> > > > I guess I can do that, though it can be very messy if any of them are
> > > > forced to make their commits unstable. It also creates headaches,
> > > > AIUI, for sfr if my tree suddenly gains a bunch of other trees so it's
> > > > not clear where something came from.
> > >
> > > I don't have a problem with trees in linux-next sharing *commits* - I
> > > have problems when they share *patches* that are different commits
> > > (that affect files that get changed in other commits).
> >
> > Do we have any sane way to overcome this limitation?
> >
> > I tried to add my tree [1] to participate in linux-next. My tree
> > includes my submission queue and important patches posted to the mailing list
> > to the RDMA subsystem.
> >
> > The absence of ability to add parallel tree with same commits doesn't allow us
> > effectively test the RDMA patches.
>
> Why do you need "parallel" trees in linux-next?  What is that going to
> help with?

We are developing against two subsystems at the same time (netdev vs. RDMA) and need
to ensure that combination of them is working. Currently me (RDMA) and Saeed (netdev)
are merging out trees by ourselves [1] and instructs our verification (end-to-end and
QA) to run from that tree.

It means that we are missing a lot of stuff related to PCI, nvme, vitalization and storage
where our technology is used.

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.

And the situation is worse when someone posts patches which has potential to break
other vendors.

Ability to have "parallel" trees will allow us to run our (other vendors expressed the same
desire) verification on top of linux-next with all goodies of automatic regression systems
which we have as a hardware vendor.

So I would like to have "parallel" tree where I can put all my RDMA patches + important patches
from other parties and run from linux-next.

>
> > The reasons to it are combination of mostly two factors: my tree is not
> > official one [2] (all patches in my tree are not officially final) and very
> > sporadic update very close and/or during merge window [3].
>
> If it's not "official", why should it be in linux-next?

Because, official updates occur mostly twice in the cycle on -rc3 (for fixes)
and before merge window, while it is too late for us because we are preparing
our submission queues for next cycle (Linus's requirement for Mellanox's
submissions) and verification is busy with that.

Thanks

[1] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/ branches:queue-next and queue-rc
[2] https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=testing/queue-next
>
> thanks,
>
> greg k-h

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]