On Thu, Feb 04, 2021 at 03:21:24PM +0000, Lee Jones wrote:

> The default point-of-view is; if a patch was submitted as part of a
> set, it's likely that it makes the most sense to merge it as a set.

Blocking the whole series is itself not ideal since it means the whole
large series keeps on getting resent for minor changes in individual
patches where it's only a small number of leaf patches that have issues, 
with a lot of these serieses the reason they're bundled together is that
there's some constants being added in one of the early patches that gets
used everywhere else, not that there's a really a particularly strong
relationship.

> Very often sets will have inter-dependencies (usually headers) which
> would otherwise require the base patches to be applied (perhaps the
> MFD core and the headers) in one release, followed by the accompanying
> child device changes during a subsequent release.  This doesn't scale
> well and puts the contributor in an unfair position.

You had been sharing pull requests for the common bits in the past which
had resolved the dependency issues?

> This is how we usually work together.  Why is ASoC so different?

Like I say we've got active work that ends up doing subsystem wide
interface changes on a fairly frequent basis which then creates issues
if a new user pops up that's still trying to use the old API.  Often
it's fine but coordinating near the time is safer than just acking with
a potentially long lead time on things actually going through.