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

[Linus Walleij]

On Wed, Sep 5, 2018 at 11:00 AM Daniel Vetter <daniel.vetter at 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:

- Classify the components into embargoed and non-embargoed
  so anything not affected by embargo can be pushed upstream.
  (OK it's maybe obvious).

- 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. This is a property of the company
  "FOSS-OUT legal process" that is simple but still often
  forgotten. It relieves the developers for the need to hammer
  management for approvals.

- Use internal developers with high upstream experience and
  NDA to make internal reviews and try to anticipate any problems
  that will be seen when posting the code to the community and
  fix it before it happens. Get the code in upstream shape.
  (This is a good reason to hire kernel maintainers and have them
  spend time upstream BTW.)

- Minimize hamming distance to mainline, which means rebase
  internal development as often as possible, track mainline,
  bring in entire branches of development if need be just to not
  deviate, because deviating too much from mainline is inviting
  disaster. This goes counter to the conventional wisdom that
  says you should use stable releases and baselines and LTS
  and what not. I am not a big fan of the latter. Rebase on
  Torvald's -rcN or even linux-next if you are aiming for upstream,
  else you are not really aiming for upstream, but secondary
  goals such as feature completion, "not disturbing development",
  or getting tests to pass cleanly all the time. Get your priorities
  straight: is upstream first really what you want? Then that
  should be priority number one, not feature completion, not
  "not disturbing developers", not passing internal tests.
  If you find upstream first isn't really your number one priority
  then call your strategy upstream second or upstream
  third so that it reflects reality instead of trying to sound good.

The last point was always the most controversial.

Just my €0.01
Linus Walleij