From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CCD32DC3 for ; Thu, 6 Sep 2018 10:25:34 +0000 (UTC) Received: from mail-qt0-f196.google.com (mail-qt0-f196.google.com [209.85.216.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 624EF8B for ; Thu, 6 Sep 2018 10:25:34 +0000 (UTC) Received: by mail-qt0-f196.google.com with SMTP id o15-v6so11572314qtk.6 for ; Thu, 06 Sep 2018 03:25:34 -0700 (PDT) MIME-Version: 1.0 References: <20180905042246.GA2977@mtr-leonro.mtl.com> <20180905074840.GB29052@kroah.com> <20180905083120.GA28353@kroah.com> In-Reply-To: From: Arnd Bergmann Date: Thu, 6 Sep 2018 12:25:16 +0200 Message-ID: To: Linus Walleij Content-Type: text/plain; charset="UTF-8" Cc: ksummit , gregkh Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Challenges in Upstream vs. Embargoed Development in Intel Graphics. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Sep 6, 2018 at 11:54 AM Linus Walleij wrote: > > On Wed, Sep 5, 2018 at 11:00 AM Daniel Vetter wrote: > > > I have no idea how this works outside of intel or graphics, I tend to > > not chat with those people as much as I do with graphics people. Would > > be interesting to know how it is outside of the graphics bubble > > indeed. > > More or less any SoC company for routers, handsets, tablets etc > have the same problem. > > At one point I was made responsible for such a scenario. The > approach I developed was a bit ad hoc but contained some of this: Thanks for sharing those. > - Get management to provide a cut-off date for embargo. Like > "after this point in time we certainly do not care what code you > publish pertaining to X" and make that formal so that when that > day comes developers can simply start sending the code without > having to ask permission again, because having to do that is > pointless and bureaucratic. 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. That is mainly what I remember from working on enterprise hardware in a previous job: you are either based on a distro schedule (needs to be posted/reviewed/integrated by date X to have a chance to make it into future product Y), or on a hardware schedule (needs to be posted X months ahead of HW product launch to have a reasonable chance of making it into software products by the time the hardware makes it into customer's hands). Having both the earliest date (for information embargo) and latest date (for software integration) gives you a nice way to estimate how likely the software is going to make it in time. Arnd