public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
	lgirdwood@gmail.com
Subject: Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR
Date: Fri, 24 May 2019 12:56:59 +0100	[thread overview]
Message-ID: <20190524115659.GC2456@sirena.org.uk> (raw)
In-Reply-To: <e7f332a3-ce4b-a058-74b3-3dfd8bccfbc8@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-05-24 11:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21 20:30 [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR Jacek Anaszewski
2019-05-21 21:15 ` Mark Brown
2019-05-22  0:48   ` Dan Murphy
2019-05-22 10:59     ` Mark Brown
2019-05-22 18:27   ` Jacek Anaszewski
2019-05-22 19:02     ` Mark Brown
2019-05-29 20:44       ` Jacek Anaszewski
2019-05-22  5:42 ` Lee Jones
2019-05-22 19:01   ` Jacek Anaszewski
2019-05-23  8:31     ` Lee Jones
2019-05-23 20:07       ` Jacek Anaszewski
2019-05-24 11:56         ` Mark Brown [this message]
2019-05-29 20:44           ` Jacek Anaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190524115659.GC2456@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox