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 9E06B2C for ; Sun, 30 Apr 2017 19:12:08 +0000 (UTC) Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB08E1A0 for ; Sun, 30 Apr 2017 19:12:07 +0000 (UTC) Received: by mail-ua0-f177.google.com with SMTP id q26so22801361uaa.1 for ; Sun, 30 Apr 2017 12:12:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20170425091058.qhxkpocnhhd4jysh@dell> From: Olof Johansson Date: Sun, 30 Apr 2017 12:12:06 -0700 Message-ID: To: Daniel Vetter Content-Type: text/plain; charset=UTF-8 Cc: ksummit , Dave Airlie , Greg Kroah-Hartman , David Miller , Doug Ledford , Ingo Molnar Subject: Re: [Ksummit-discuss] "Maintainer summit" invitation discussion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, Apr 29, 2017 at 2:00 PM, Daniel Vetter wrote: > [Back from a bit of vacation, so I'm just jumping into the middle of > the cross-subsystem/invariant topic branch discussion. I read all the > other mails, but this seems most relevant.] > > On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones wrote: >> Although common place, immutable branches are still treated as the >> last resort. If patches can be taken via their respective subsystem >> trees without fear of disruption, they are. Contributors often >> attempt to have their *new* cross-subsystem functionality taken in via >> a single tree (requiring an immutable branch), purely because it's >> convenient and the merge-time becomes deterministic, but we do not >> allow that unless there are hard/unavoidable build-time dependencies. > > Honest question, why exactly? > > At a quick ignorant glance this seems to trade contributor time > against maintainer time, which in my opinion means you should ramp up > your maintainer training and mentoring to have much more maintainer > time available and make contributing to upstream more attractive. But > drm != other subsystems, I'd like to hear more of why you picked this > tradeoff. As mentioned already, we've seen too many messes caused by multiple people stepping on each other. When you merge a mixed-contents branch through another subsystem you have to gamble on anyone else not touching anything near it. Worst case possible is refactorings of code made by people at the same time, with the almost-as-bad-case of one side refactoring, the other one adding something new. And given how refactoring-happy DRM is, I'm extremely hesitant to see ARM contents merged through there. Another reason for that is that it's pretty common to have for example media and graphics handled by separate teams from main platform code (both in corporate land as well as on the community side). Having two separate teams work on the same piece of code means that even though _you_ say it's OK to merge through a different tree, the platform maintainer on the other team might have different plans for that code. Yes, there's some overhead in dealing with this. Most of it is pushed down to the per-platform level, so there's no need to coordinate all the way up the maintainer path in many cases. Main exception is usually new contributors/platforms where we keep an extra eye on things as new people get used to their roles, build up experience, etc. -Olof