linux-kernel - cross-merges with MFD tree (was: Re: GFS2: Pull Request)

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]

Date:   Tue, 28 May 2019 20:55:30 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        Lee Jones <lee.jones@...aro.org>,
        Mark Brown <broonie@...nel.org>
Subject: cross-merges with MFD tree (was: Re: GFS2: Pull Request)

Hi Linus,

On 5/8/19 7:55 PM, Linus Torvalds wrote:
> On Wed, May 8, 2019 at 4:49 AM Andreas Gruenbacher <agruenba@...hat.com> wrote:
>>
>> There was a conflict with commit 2b070cfe582b ("block: remove the i
>> argument to bio_for_each_segment_all") on Jens's block layer changes
>> which you've already merged. I've resolved that by merging those block
>> layer changes; please let me know if you want this done differently.
> 
> PLEASE.
> 
> I say this to somebody pretty much every single merge window: don't do
> merges for me.
> 
> You are actually just hurting, not helping. I want to know what the
> conflicts are, not by being told after-the-fact, but by just seeing
> them and resolving them.
> 
> Yes, I like being _warned_ ahead of time - partly just as a heads up
> to me, but partly also to show that the maintainers are aware of the
> notifications from linux-next, and that linux-next is working as
> intended, and people aren't just ignoring what it reports.
> 
> But I do *NOT* want to see maintainers cross-merging each others trees.

I would like to clarify if this applies to immutable integration
branches that are usually created for MFD subsystem. That subsystem
is somehow specific since changes made to MFD drivers are often a part
of bigger patch sets that add drivers of MFD cells to the other
subsystems.

Like in my area of interest an addition of a driver for LED cell
of MFD device must be followed by addition of a corresponding entry to
struct mfd_cell array in the related MFD driver.

And sometimes even another subsystem is involved, like e.g. regulator
framework in case of recent extension of ti-lmu driver.

So far you haven't complained about this specific workflow, but I'd like
to make sure how you see it.

-- 
Best regards,
Jacek Anaszewski