From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932873AbdIFPCq (ORCPT ); Wed, 6 Sep 2017 11:02:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:33064 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932659AbdIFPCn (ORCPT ); Wed, 6 Sep 2017 11:02:43 -0400 Date: Wed, 06 Sep 2017 17:02:41 +0200 Message-ID: From: Takashi Iwai To: Lee Jones Cc: "Rafael J. Wysocki" , Darren Hart , Andy Shevchenko , Mika Westerberg , Johannes Stezenbach , Hans de Goede , Dmitry Torokhov , platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC In-Reply-To: <20170906145432.szhmst6lhnuau6nz@dell> References: <20170905072451.ephscqjqgwpnl6da@dell> <20170906104040.jtribzvrutdgmtqt@dell> <2820948.LZW4fHiiGQ@aspire.rjw.lan> <20170906135113.vztfak2bumqpjhos@dell> <20170906145432.szhmst6lhnuau6nz@dell> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 06 Sep 2017 16:54:32 +0200, Lee Jones wrote: > > > > > Right, and that's really fundamental, because then the user can tell you > > > > "look, this commit doesn't work for me" instead of just "this kernel > > > > doesn't work for me" and now you need to spend *your* time on trying to > > > > figure out which commit may be at fault. > > > > > > > > So speaking of benefits, I really prefer to avoid spending my time on > > > > such things. :-) > > > > > > The toss-up is between splitting the patch-set up and *maybe* spending > > > time on debugging in the small chance of this occurring OR > > > *definitely* spending time creating immutable branches and sending out > > > pull-requests in the *hope* that all the other Maintainers involved > > > are diligent enough to merge it in order to avoid conflicts during > > > merge time. > > > > > > In the circles I spend time in ("we"), the former is the favourite. > > > > This certainly depends on the complexity. For a small patchset, > > merging in a shot is often a safer option. That is, when all parties > > agree, you can just apply all patches to your branch -- that's all. > > Other parties can simply pull this from your branch if needed. Of > > course, the branch needs to be immutable for that, but usually it's no > > big problem. (Ideally speaking, all the published branches should be > > persistent in anyway.) > > > > IIUC, it's the way Andy and Rafael suggested in the thread, and also > > seen in many other subsystems occasionally. > > > > > Until this point (and from this point going forward) we have taken the > > > decision that the default is to take individual patches through their > > > own trees. The only time this differs (unless other arrangements are > > > made e.g. PATCH 3/3) is when there are; build, merge or API > > > dependencies between them. The same stance is taken with > > > driver/platform data and driver/other driver. > > > > > > Let me put one of the issues into context: > > > > > > For those reading along that do not know, Multi-Functional Devices are > > > usually single pieces of silicon which provide many functions > > > (e.g. LED Controllers, Voltage Regulation, Power Management, Sensors, > > > Timers, GPIO/Pinctrl Controllers, Watchdog Timers, Real-Time Clocks, > > > etc etc). The driver which sits in drivers/mfd acts as the parent > > > device and registers its children which live in their own subsystems. > > > > > > Almost all of the patch-sets I receive touch multiple subsystems. > > > Moreover, when the recently described dependencies occur, it is > > > usually I who creates the immutable branches and sends out the > > > pull-requests. > > > > > > If I had to go through the immutable branch/pull-request process for > > > every patch-set I receive, there would be very little time to conduct > > > duties pertaining to my proper job. Ergo, why we apply our own > > > patches, unless there is a good reason (already described) to apply > > > others too. > > > > Hm, I never thought that creating an immutable branch were so > > difficult. Isn't it just a simple branch-off either from the certain > > upstream point (final release or rc) or from your stable branch? > > You'd be surprised. > > When applying patches, I normally apply them to a mail folder for > further processing. This works great for patches that are applied to > my main branch, but this does not work for immutable branches. These > have to be applied on their own, thus need a 'special' or at least an > empty folder. Well, this isn't always requested -- at least, the simple case like this one doesn't need to treat so much specially. We just need a persistent branch that will be never rebased. It's the only requirement. That said, it's even enough just to branch off from your normal MFD development branch, by a simple guarantee that you won't rebase *that* branch any longer. So, it's also a kind of "immutable branch", but it's much easier than your regular workflow for the complex merge below. Of course, a "cleaner" branch is preferred, but it doesn't matter much as long as all stuff there will be merged to upstream sooner or later. thanks, Takashi > > - Checkout a new branch based on the same (or earlier, but I always > use the same) commit as the main branch. > > - Apply the patches in the normal way, only this time you usually need > to interactively rebase and 'reword' them to add any missing > Acks/Reviewed-bys. > > - Tag and sign the branch with a suitable tag name and tag > description. > > - Push branch and tag > > - Create pull-request text > > - Send a formatted email with the pull-request text. > > This process is quite a lot more involved than simply applying > relevant patches to your main branch, and as I say, if this was > required for all patch-sets I am sent or involved in, it would really > eat into my day. > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog >