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.
Attachment:
signature.asc
Description: PGP signature
