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 1068FB55 for ; Tue, 2 May 2017 08:09:21 +0000 (UTC) Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52C43155 for ; Tue, 2 May 2017 08:09:20 +0000 (UTC) Received: by mail-wr0-f175.google.com with SMTP id l50so73945353wrc.3 for ; Tue, 02 May 2017 01:09:20 -0700 (PDT) Date: Tue, 2 May 2017 09:09:15 +0100 From: Lee Jones To: Daniel Vetter Message-ID: <20170502080915.jfvmticdqmaygndt@dell> References: <20170425091058.qhxkpocnhhd4jysh@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Sat, 29 Apr 2017, 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. It looks like James et. al. have provided some pretty good technical reasons as to why taking patches via their associated subsystem repos is *always* preferred, so I will not labour this point. However I will provide a frank answer to your trading Maintainer for Contributor time query. To be candid, you're right we do that, and it's exactly what we should be doing. There are a couple of reasons for this: The first is a simple matter of time related mathematics. Taking an average over the past 10 releases, MFD and Backlight had ~30 unique submitters per release. If even some of them managed to get themselves into habits which cost me more time than it already does to Maintain the subsystems, then either the Maintainership or my employment role would be negatively impacted. I view it better to cost each Contributor 30 mins, than it to cost me 30 mins multiplied by the amount of Contributors. Moreover, most Contributors are doing so *as part* of their employment role, where-as myself and a great many other Maintainers are operating *as well as*, or outside of ours. Secondly, this is about Contributor training and the encouragement of good practices from the outset; patch separation, expert reviews, conflict mitigation, bisection preservation, etc etc. If we train and arm the Contributors of today, we inherently encourage the Maintainers of tomorrow. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog