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

[Greg KH <greg@kroah.com>]

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?

> 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?

thanks,

greg k-h