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