Messages in this thread | | | Date | Thu, 4 Feb 2021 16:48:26 +0000 | From | Mark Brown <> | Subject | Re: [PATCH v4 0/5] MFD/ASoC: Add support for Intel Bay Trail boards with WM5102 codec |
| |
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. [unhandled content-type:application/pgp-signature] | |