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

[Jacek Anaszewski]

On 5/23/19 10:31 AM, Lee Jones wrote:
> On Wed, 22 May 2019, Jacek Anaszewski wrote:
>
> > On 5/22/19 7:42 AM, Lee Jones wrote:
> > > On Tue, 21 May 2019, Jacek Anaszewski wrote:
> > >
> > > > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
> > > >
> > > >     Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
> > > >
> > > > are available in the git repository at:
> > > >
> > > >     git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/ti-lmu-led-drivers
> > > >
> > > > for you to fetch changes up to 13f5750a60b923d8f3f0e23902f2ece46dd733d7:
> > > >
> > > >     leds: lm36274: Introduce the TI LM36274 LED driver (2019-05-21 20:34:19 +0200)
> > > >
> > > > ----------------------------------------------------------------
> > > > TI LMU LED support rework and introduction of two new drivers
> > > > with DT bindings:
> > > >
> > > > - leds-lm3697 (entails additions to lm363x-regulator.c)
> > > > - leds-lm36274
> > > > ----------------------------------------------------------------
> > > > Dan Murphy (12):
> > >
> > > >         dt-bindings: mfd: LMU: Add the ramp up/down property
> > > >         dt-bindings: mfd: LMU: Add ti,brightness-resolution
> > > >         mfd: ti-lmu: Remove support for LM3697
> > > >         mfd: ti-lmu: Add LM36274 support to the ti-lmu
> > >
> > > These patches were Acked "for my own reference", which means I'd
> > > at least expect a discussion on how/where they would be applied.
> > >
> > > It's fine for them to go in via the LED tree in this instance and I do
> > > thank you for sending a PR.  Next time can we at least agree on the
> > > route-in though please?
> >
> > Usually ack from the colliding subsystem maintainer means he
> > acknowledges the patch and gives silent approval for merging
> > it via the other tree.
>
> Usually the type of Ack you mention takes this form:
>
>    Acked-by: Lee Jones <lee.jones@xxxxxxxxxx>
>
> However, the one I provided looks like this:
>
>    For my own reference:
>      Acked-for-MFD-by: Lee Jones <lee.jones@xxxxxxxxxx>
>
> Which clearly says "for my own reference" and not to be taken as an
> indication that it's okay for the patch(es) to go in via another
> tree.
>
> > This is the usual workflow e.g. in case of massive reworks
> > of commonly shared kernel APIs.
> >
> > Your Acked-for-MFD-by tag is not documented anywhere and I've just
> > found out about its exact meaning :-) Note also that it percolated
> > to the mainline git history probably because people mistakenly assumed
> > it was some new convention (despite that checkpatch.pl complains about
> > it). So far there are 12 occurrences thereof in git. I must admit that
> > I once unduly made my contribution to that mess.
>
> Being MFD maintainer presents an uncommon and awkward scenario.  MFD
> is special in that it means we have to work more cross-subsystem than
> most (any?).  The default for MFD related patch-sets which traverse
> multiple subsystem is for them to go in via MFD with Acks from all the
> other maintainers.  I'm always happy to discuss different merge
> strategies, but using the MFD repo is the norm.
>
> The Acked-*-by you see above came as a result of a conversation
> between myself and Maintainers I work with the most.  It was seen as
> the most succinct way of saying that the patch has been reviewed,
> whilst providing the least amount of confusion w.r.t. whether it's
> okay to be applied to another tree or not.  The "for my own reference"
> should be clear enough that I provide that tag for my own purposes,
> rather than an okay for others to merge it.
>
> > Of course, now being taught about the exact meaning of the tag,
> > I will proceed accordingly.
>
> I'd appreciate that, thank you.
>
> > Regarding this one - please hold on for a while with pulling
> > the stuff, since we may have some updates from REGULATOR maintainers
> > (hopefully Acked-by).
>
> I haven't pulled this yet, but please bear in mind ...
>
> 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.

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

At the occasion of the situation we have currently, I'd like to clarify
if cross-merges between MFD and other subsystems deserve special
treatment.

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 precisely why I usually find it better for patches to go in
> via the MFD tree.
>
> [0] [GIT PULL] LM3532 backlight support improvements and relocation

[0] https://lkml.org/lkml/2019/5/8/820

--
Best regards,
Jacek Anaszewski