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

[Rodrigo Vivi <rodrigo.vivi@gmail.com>]

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

On Thu, Sep 6, 2018 at 2: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 a lot for sharing and thanks to the others who commented after
that.


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

It is obvious but it is important to highlight, otherwise things might
get stuck in the pipe just because it is unclear and people get afraid
to sign-off something that might be seen as a "leak".


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

Yes, on the internal front of the battle we are already doing this
and trying to get even earlier embargo-lifted decisions.


>
> - 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.)
>

Yeap, we are trying to do the same here.


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

It is interesting. In the past I also thought the frequent rebases were
controversial
and maybe kind of insane to keep rebasing. But one of the key lessons we
had is that rebase often is not fast enough still. But keeping it in
constant rebase is easier and cheaper than rebase often. And definitely
cheper than loosing code with the famous "technical debt"
For every week that I kept the BOT disabled and blocked I regretted so
badly. When that happened I had to expend another full week only fixing
conflicts.
If code didn't change much yet, git and patch don't get lost easily. But if
they get lost, wiggle or manual inspection can get it faster.
But when code changed a lot like on -rc1 then the conflict is more a
forward-port as painful the backport and risky.

But of course, a key part of the constant rebase is CI. We constantly
rebase on top of drm-tip that has CI for every patch pre and post merge.
And we also have CI on internal branch for every rebasing point.


>
> Just my €0.01
> Linus Walleij
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

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