Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp350727ybi; Fri, 24 May 2019 04:58:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqz3Iwb/I5UR0/HZGVOsDGJyxtYm1TuEeqUcltfvwSgx3BH7Xpy83nkreLWMvEHEVnLVySxy X-Received: by 2002:a17:902:1347:: with SMTP id r7mr61711373ple.45.1558699116367; Fri, 24 May 2019 04:58:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558699116; cv=none; d=google.com; s=arc-20160816; b=NRV3EWM7MxjDOE6zkEK6uXVLSyjOAl7i72ouy2cX5UctdXrsnvVn4Jav+92MBQkHsE kTPtxU18cSeeC1jrPHWnawMfpGxdXB0QVf0kkaYafmymTu1AUEwLmVKPdNYm3AdxfJXV p15kmptVqYztu6HMII3s/0dyDZF/RuharwMft1mgpKJ0sdf+LUct42xm3GUnS1ao0wBF YOUMX17lDh5Q4s/UGOJQl0G1LMuGmZILETd2veZOdKsAoVyrgFj3bta83beyAr15ug8k eT8TTB0DspzhFE/bAqlx7+tzzNIOgj0ADwoiIDjudOyG4lqA3lWDgTU59GEvqkaxJUJo RtsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=UUh+8+/lF5nObSY6PMVsFDBwtwtanNqftEqtZfrQEdA=; b=bh5ZyB+vRM32WGOfISO9HbWSLrOwIqPPTs+o+Y+NZthHvYBYKQsH4QuEBbAevzCVDD pkNds6sx70VQyzRr8C++Lo2e99BpKWLN3+muNYypYBtH5VssWVMcPrHq9IkNTBUdWBTJ WSlOb5ULZd6chEBLSLHMLqXsMz4pWspvbKhne9UGcEt5+bdG1zCr7RIVAGfwBI6fNaTf tLOzHbVIFJ2Ox4kg6X6CMlcwfPGK7+oO3uaZZOQ2uEEQNRUXoBOp/cgxWOXyeB0UhNhK IrzbiMviCFpI3A3e9dKCWv3b5eUof7oEEzS2WD+xlaq44gmn97y/AMDC6IwKtknMYI/8 RtFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=fdEgooYj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k190si3790055pgd.283.2019.05.24.04.58.21; Fri, 24 May 2019 04:58:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=fdEgooYj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391408AbfEXL5P (ORCPT + 99 others); Fri, 24 May 2019 07:57:15 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:45226 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391195AbfEXL5O (ORCPT ); Fri, 24 May 2019 07:57:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UUh+8+/lF5nObSY6PMVsFDBwtwtanNqftEqtZfrQEdA=; b=fdEgooYjTAmXswwglf48pIJR6 ZQ7B7c4QM1ozuwpsECe0pIi71lEJ/8A0C2Yb47VHfeuEn8OVA0/c6IBZ07CHXx+lMEUENPzV87h39 I470Cf8gXp3CxeKnbTNJ2GMcv3bPm5y3JLu8I0s1enm9saaivtXRhCcFYf5cHxq5XC/tc=; Received: from [176.12.107.140] (helo=finisterre.sirena.org.uk) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hU8om-0003BY-U5; Fri, 24 May 2019 11:57:01 +0000 Received: by finisterre.sirena.org.uk (Postfix, from userid 1000) id E912B440046; Fri, 24 May 2019 12:56:59 +0100 (BST) Date: Fri, 24 May 2019 12:56:59 +0100 From: Mark Brown To: Jacek Anaszewski Cc: Lee Jones , linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org, lgirdwood@gmail.com Subject: Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR Message-ID: <20190524115659.GC2456@sirena.org.uk> References: <20190521203038.31946-1-jacek.anaszewski@gmail.com> <20190522054256.GA4574@dell> <3492171a-bcdc-bee2-684c-e1029653a811@gmail.com> <20190523083129.GH4574@dell> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Izn7cH1Com+I3R9J" Content-Disposition: inline In-Reply-To: X-Cookie: The other line moves faster. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 23, 2019 at 10:07:35PM +0200, Jacek Anaszewski wrote: > On 5/23/19 10:31 AM, Lee Jones wrote: > > Once an immutable branch is created, it should never, ever change. I > > think this is the second pull-request I've had from you [0] and the > > second one you've wanted to retract. That should not happen! > This is life - it is always possible that some problems will be > detected in linux-next later in the cycle, either by bots or by other > people. If you've created an immutable branch that other people might have merged you should be doing incremental fixes on top of it and not changing it unless you've confirmed that nobody else merged it, that's the whole immutable thing. If you rebase the commits are still going to be in other people's trees and will still end up getting merged which makes a mess. > Some time ago I referred to Linus' message from 2017 discouraging > maintainers from cross-merging their trees, which you didn't find > applicable to existing MFD workflow. > Recently Linus put stress on that again [0]. There's a difference between just grabbing someone's whole tree and pulling in a targetted topic branch with only specific overlapping stuff. There's also no requirement on people to immediately merge=20 such a topic branch, they can always just keep it on file until it=20 does become important for dependencies. A lot of the MFD cross tree merges are happening because constants introduced in the MFD tree become build dependencies for other trees. Historically there were maintainers who just randomly merged people's entire trees which does cause lots of problems, this isn't that. > So please, if you find it reasonable to proceed with these immutable > branches workflow, I would first prefer to see Linus' approval for that. This is nothing new. --Izn7cH1Com+I3R9J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlzn3AsACgkQJNaLcl1U h9CzPQf/XQWXb/SlOinfwRA5a0iVYS+aE687fICb19kdMNAglAUAXsOe9FQTLaqU Jd48YIZ2UyPm4Noa1d3p+dnReu/WBqtq+7m5tjIXIblan+0r39xmpuwIm+t/zh71 fSjUCaYXW/4T/0mXxWr0G4pXOR57O30TgmR9Lr0NVg5jOVxpyzz9Ein/wfeOpPq/ HUAujAljW4pIYcJzQS3LO7svmUwtVakxzfWLIgqI27UfaMto6ANJpW/Ib0fpJYnR ruErQB2EtDvZz4KqH/MxuzAOIYPhy/InAx3UkOg9nO1hMGGgfntaWB3Eu4H5GC9Z +ep3ZXv7fhqamBL/Y0tk0RynfarR5g== =EqwU -----END PGP SIGNATURE----- --Izn7cH1Com+I3R9J--