Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai <tiwai@suse.de>]

On Wed, 06 Sep 2017 16:54:32 +0200,
Lee Jones wrote:
> 
> > > > Right, and that's really fundamental, because then the user can tell you
> > > > "look, this commit doesn't work for me" instead of just "this kernel
> > > > doesn't work for me" and now you need to spend *your* time on trying to
> > > > figure out which commit may be at fault.
> > > > 
> > > > So speaking of benefits, I really prefer to avoid spending my time on
> > > > such things. :-)
> > > 
> > > The toss-up is between splitting the patch-set up and *maybe* spending
> > > time on debugging in the small chance of this occurring OR
> > > *definitely* spending time creating immutable branches and sending out
> > > pull-requests in the *hope* that all the other Maintainers involved
> > > are diligent enough to merge it in order to avoid conflicts during
> > > merge time.
> > > 
> > > In the circles I spend time in ("we"), the former is the favourite.
> > 
> > This certainly depends on the complexity.  For a small patchset,
> > merging in a shot is often a safer option.  That is, when all parties
> > agree, you can just apply all patches to your branch -- that's all.
> > Other parties can simply pull this from your branch if needed.  Of
> > course, the branch needs to be immutable for that, but usually it's no
> > big problem.  (Ideally speaking, all the published branches should be
> > persistent in anyway.)
> > 
> > IIUC, it's the way Andy and Rafael suggested in the thread, and also
> > seen in many other subsystems occasionally.
> > 
> > > Until this point (and from this point going forward) we have taken the
> > > decision that the default is to take individual patches through their
> > > own trees.  The only time this differs (unless other arrangements are
> > > made e.g. PATCH 3/3) is when there are; build, merge or API
> > > dependencies between them.  The same stance is taken with
> > > driver/platform data and driver/other driver.
> > > 
> > > Let me put one of the issues into context:
> > > 
> > > For those reading along that do not know, Multi-Functional Devices are
> > > usually single pieces of silicon which provide many functions
> > > (e.g. LED Controllers, Voltage Regulation, Power Management, Sensors,
> > > Timers, GPIO/Pinctrl Controllers, Watchdog Timers, Real-Time Clocks,
> > > etc etc).  The driver which sits in drivers/mfd acts as the parent
> > > device and registers its children which live in their own subsystems.
> > > 
> > > Almost all of the patch-sets I receive touch multiple subsystems.
> > > Moreover, when the recently described dependencies occur, it is
> > > usually I who creates the immutable branches and sends out the
> > > pull-requests.
> > > 
> > > If I had to go through the immutable branch/pull-request process for
> > > every patch-set I receive, there would be very little time to conduct
> > > duties pertaining to my proper job.  Ergo, why we apply our own
> > > patches, unless there is a good reason (already described) to apply
> > > others too.
> > 
> > Hm, I never thought that creating an immutable branch were so
> > difficult.  Isn't it just a simple branch-off either from the certain
> > upstream point (final release or rc) or from your stable branch?
> 
> You'd be surprised.
> 
> When applying patches, I normally apply them to a mail folder for
> further processing.  This works great for patches that are applied to
> my main branch, but this does not work for immutable branches.  These
> have to be applied on their own, thus need a 'special' or at least an
> empty folder.

Well, this isn't always requested -- at least, the simple case like
this one doesn't need to treat so much specially.  We just need a
persistent branch that will be never rebased.  It's the only
requirement.

That said, it's even enough just to branch off from your normal MFD
development branch, by a simple guarantee that you won't rebase *that*
branch any longer.

So, it's also a kind of "immutable branch", but it's much easier than
your regular workflow for the complex merge below.

Of course, a "cleaner" branch is preferred, but it doesn't matter much
as long as all stuff there will be merged to upstream sooner or
later.


thanks,

Takashi

> 
> - Checkout a new branch based on the same (or earlier, but I always
> use the same) commit as the main branch.
> 
> - Apply the patches in the normal way, only this time you usually need
> to interactively rebase and 'reword' them to add any missing
> Acks/Reviewed-bys.
> 
> - Tag and sign the branch with a suitable tag name and tag
> description. 
> 
> - Push branch and tag
> 
> - Create pull-request text
> 
> - Send a formatted email with the pull-request text.
> 
> This process is quite a lot more involved than simply applying
> relevant patches to your main branch, and as I say, if this was
> required for all patch-sets I am sent or involved in, it would really
> eat into my day.
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
>