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 ED677BE5 for ; Mon, 24 Apr 2017 17:29:08 +0000 (UTC) Received: from mail-vk0-f66.google.com (mail-vk0-f66.google.com [209.85.213.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 450B5170 for ; Mon, 24 Apr 2017 17:29:05 +0000 (UTC) Received: by mail-vk0-f66.google.com with SMTP id j135so5900346vka.2 for ; Mon, 24 Apr 2017 10:29:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Olof Johansson Date: Mon, 24 Apr 2017 10:29:02 -0700 Message-ID: To: Linus Walleij Content-Type: text/plain; charset=UTF-8 Cc: ksummit , Dave Airlie , David Miller , Doug Ledford , Greg Kroah-Hartman , Ingo Molnar Subject: Re: [Ksummit-discuss] "Maintainer summit" invitation discussion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Apr 24, 2017 at 9:17 AM, Linus Walleij wrote: > 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. Yeah, Lee has been doing a good job there (even though we always double-check about immutable branches to make the producer aware that we've picked it up). The clk maintainers (Mike/Stephen) have been doing a good job too where they tend to apply patches on a per-driver branch that they keep immutable. In the clk case we've been pushing back against the "add a branch dependency just to add one numerical define use" that has been common for incremental changes that affect clk and DT contents, instead asking people to revisit with a follow-up patch either right after -rc1 or next release. -Olof