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.