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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190524115659.GC2456@sirena.org.uk>
Date:   Fri, 24 May 2019 12:56:59 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
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

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 
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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)