Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932585AbbELMDh (ORCPT ); Tue, 12 May 2015 08:03:37 -0400 Received: from mail-ob0-f177.google.com ([209.85.214.177]:34858 "EHLO mail-ob0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932381AbbELMDe (ORCPT ); Tue, 12 May 2015 08:03:34 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 12 May 2015 14:03:33 +0200 Message-ID: Subject: Re: lpc18xx: undefined Kconfig option ARCH_LPC18XX From: Linus Walleij To: Valentin Rothberg Cc: Joachim Eastwood , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Alexandre Courbot , Paul Bolle , hengelein Stefan , Andreas Ruprecht Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2805 Lines: 68 On Tue, May 12, 2015 at 12:48 PM, Valentin Rothberg wrote: > On Tue, May 12, 2015 at 12:40 PM, Linus Walleij > wrote: >> On Wed, May 6, 2015 at 10:02 AM, Valentin Rothberg >> wrote: >> >>> Hi Joachim, >>> >>> there are two of your commits [1, 2] in today's linux-next (i.e., >>> next-20150506). Both of them add Kconfig options that depend on >>> ARCH_LPC18XX, which is not defined in Kconfig, see: >>> >>> + depends on OF && (ARCH_LPC18XX || COMPILE_TEST) >>> >>> Is there a patch queued somewhere to add ARCH_LPC18XX ? >> >> Yes, and in this case it solves more problems to merge these >> patches out-of-order than not to. > > Could you explain those problems? I have some research interest in > such cases and want to understand and identify reasons for such > things. What we want as maintainers is to keep GIT trees in isolation without too much cross-dependencies. Often done by assuming optimistically that patches are orthogonal. Non-trivial dependencies are for example if one patch introduce a header file that another patch is using, the result will not compile, so we need to resolve to the exit strategies of: - (A) Applying the same patch to two trees, which will be handled by git as the patches are textually identical. - (B) Creating an immutable branch pulled into both trees, which is better since it means the same hash is in both trees - (C) apply to one tree, wait for the merge window, and postpone to the next kernel cycle, which delays development Whenever we can orthogonalize patches it makes our job easier. Kconfig symbols added in one tree and used in another does not create compilation wreckage and will resolve nicely in linux-next and during the merge window, however the trees still have a formal dependency which would argue that you should go back to option (B) above in the ideal case and create an immutable branch. However doing that for something that you, as a human maintainer, know will fix itself later, is surplus process for the sake of process and "never making mistakes" which cost more than it yields in maintainer time, thus making it a time-cost economically rational decision not to go to all the trouble of setting up an immutable branch but instead rely on some uncertainty and laziness to save time. The answer to whether a certain maintainer will dare to do so or not is per individual preference. The crucial point is that "time savings" trumps "nothing can ever go wrong". Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/