linux-kernel - Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d9fa3435-a942-b6e4-c510-e70c59deae61@gmail.com>
Date:   Wed, 29 May 2019 22:44:01 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Lee Jones <lee.jones@...aro.org>, linux-leds@...r.kernel.org,
        linux-kernel@...r.kernel.org, lgirdwood@...il.com
Subject: Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

I've just noticed gmail redirected this message to the Spam folder.
I will have to improve my filters to secure myself against that.

Sorry for late reply and maybe unnecessary escalation of the issue.

On 5/24/19 1:56 PM, Mark Brown wrote:
> 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.

That's obvious. I checked that the branch wasn't pulled to any of
the affected subsystems. Also double-checked it wasn't present
in linux-next at the time I was dropping the signed tag,
and updating the branch.

>> 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
> such a topic branch, they can always just keep it on file until it
> 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.

I just wanted to make sure. We will see if Linus will have something
to add.

-- 
Best regards,
Jacek Anaszewski