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

[Arnd Bergmann <arnd@arndb.de>]

On Thu, Sep 6, 2018 at 11:54 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Sep 5, 2018 at 11:00 AM Daniel Vetter <daniel.vetter@ffwll.ch> 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