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 0B621B5D for ; Mon, 24 Apr 2017 16:17:49 +0000 (UTC) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 335B710A for ; Mon, 24 Apr 2017 16:17:48 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id w12so28818062oiw.3 for ; Mon, 24 Apr 2017 09:17:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Linus Walleij Date: Mon, 24 Apr 2017 18:17:45 +0200 Message-ID: To: Daniel Vetter , Lee Jones Content-Type: text/plain; charset=UTF-8 Cc: ksummit , Dave Airlie , Greg Kroah-Hartman , Ingo Molnar , Doug Ledford , David Miller Subject: Re: [Ksummit-discuss] "Maintainer summit" invitation discussion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Apr 20, 2017 at 3:46 PM, Daniel Vetter wrote: > Might just be good to chat a bit about when exactly a topic branch is > called for, and when exactly merging through each separate tree is > better. I get a bit the feeling that merging through separate trees is > done to make sure platforms use all the infrastructure correctly > (which is the topic below), but it seems like DT managed to get there > without merging things stricly only through a DT tree. What has been mentioned about Kconfig symbols being merged in one place and then turned on in a merge commit is just part of it really. To me the big pain is always API/file dependencies. The typical case where we have to have a immutable topic branch is when there is a new API (or just a header file really) added in one patch and then a slew of patches need that API are sprinkled all over the kernel, so they by necessity need to base on this nexus commit. Essentially it happens when developers need an API from subsystem A in place to do changes in subsystems B, C, D... Also they seldom have patience to wait for a kernel cycle before making use of the API change, instead one finger on the fastforward button at all times. (I don't blame them, I am one of them.) Typical cases: I think Lee Jones could contribute to discussions around this, as he's had the painful job to coordinate queue and quite a few of these hurdles due to the nature of MFD as a connection nexus for misc. One thing he does is queue an immutable topic branch, announce it and let all affected subsystems pull it in, so that we (e.g. GPIO) can then refactor or apply local fixes in "our" subsystem from that point, even during the development cycle. It is pretty neat. Yours, Linus Walleij