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 298CBDB4 for ; Thu, 6 Sep 2018 09:54:31 +0000 (UTC) Received: from mail-it0-f67.google.com (mail-it0-f67.google.com [209.85.214.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D5B4713 for ; Thu, 6 Sep 2018 09:54:30 +0000 (UTC) Received: by mail-it0-f67.google.com with SMTP id h1-v6so13353506itj.4 for ; Thu, 06 Sep 2018 02:54:30 -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: Linus Walleij Date: Thu, 6 Sep 2018 11:54:17 +0200 Message-ID: To: Daniel Vetter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: Greg KH , ksummit-discuss@lists.linuxfoundation.org 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 Wed, Sep 5, 2018 at 11:00 AM Daniel Vetter wrot= e: > 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 =E2=82=AC0.01 Linus Walleij