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]
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ