Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Challenges in Upstream vs. Embargoed Development in Intel Graphics.

From: Rodrigo Vivi <rodrigo.vivi@gmail.com>
To: Sean Paul <seanpaul@chromium.org>
Cc: jcm@redhat.com, ksummit-discuss@lists.linuxfoundation.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Challenges in Upstream vs. Embargoed Development in Intel Graphics.
Date: Thu, 6 Sep 2018 13:41:33 -0700	[thread overview]
Message-ID: <CABVU7+u9F-uGRY0BW4N2901NUiE1fyd+cf0eV+AqoPnbZHYfnQ@mail.gmail.com> (raw)
In-Reply-To: <CAOw6vb+Uanx_wqhMa4Kv=49rPKD96HBv1PqzL-gPUTgtT153tA@mail.gmail.com>

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

On Thu, Sep 6, 2018 at 5:50 AM Sean Paul <seanpaul@chromium.org> wrote:

> On Thu, Sep 6, 2018 at 6:43 AM Linus Walleij <linus.walleij@linaro.org>
> wrote:
> >
> > On Thu, Sep 6, 2018 at 12:25 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > > I think in the generalized case, you also want the reverse, but
> > > that may be harder: When targetting specific software products
> > > that you want to integrate your code, there should be a deadline
> > > for the latest point by which code needs to be posted in
> > > public.
> >
> > This brings in the process of procurement, as in how companies
> > making products source their misc hardware like sensors,
> > touchscreens, displays, FPGAs or whatnot.
> >
> > Maybe this is obvious.
> >
> > It happened at one point that we were sourcing hardware from
> > a third party, and it was pretty complex and I asked procurement
> > to put a demand on the company to provide upstream support
> > so we could just grab the latest kernel and use that driver.
> >
> > I heard other very FOSS-oriented companies ask the same
> > and is pretty much what I've heard people like Jon Masters
> > and the Chromebook people say in relation to upstream first
> > (they can slam me if they disagree) - others also want an
> > upstream first approach from their component suppliers and
> > it is going to be part of the procurement process so having
> > upstream first is going to be a competitive advantage or
> > even strict requirement for the component vendor.
>
> Speaking really only for display, but most of this applies to other areas:
>
> Pretty much this. Chromebook display stack must use drm/kms, and the
> patches must* go upstream before landing in our kernel. Looking at our
> 4.14 branch [1], most of the commits there are
> UPSTREAM/BACKPORT/FROMGIT/FROMLIST prefixed which means they've landed
> upstream or have been reviewed upstream.
>

This firm position coming from the product directly is extremely beneficial
for us
and for open source in general.

Thanks a lot for that! :)

>
> We carry downstream patches in a separate working branch shared
> between developers and rebase on our 4.14 kernel regularly. Everything
> in the working branch should be already sent upstream or being
> polished for upstream. Reviews are done on the list. Once a patch
> lands upstream, it's backported to our kernel and removed from the
> working branch.
>
> Sean
>
> [1]-
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/chromeos-4.14/drivers/gpu/drm
>
> * There are always exceptions
>
> >
> > As it happened in my case the vendor was very unhappy
> > with this and unused to this kind of requirements. (They have
> > since changed their attitude so no-one needs to be outed.)
> >
> > What I realized was that instead of being "hard" on vendors
> > with this, I could gain more by being let's say "firm".
> >
> > I required that in order to procure their component, they
> > should present an upstreaming strategy, and post an initial
> > patch set for the specific product before we would agree
> > to procurement. This was more of a gentlemen agreement
> > than a hard contract clause, but it worked very well to
> > transform that company, and I think it is a good way, because
> > being too hard can be counter-productive, I guess it comes
> > from simple diplomacy, people do not like threats.
> >
> > Yours,
> > Linus Walleij
> > _______________________________________________
> > Ksummit-discuss mailing list
> > Ksummit-discuss@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

[-- Attachment #2: Type: text/html, Size: 5318 bytes --]