On Thu, Nov 05, 2026 at 04:46:17PM +0100, Quentin Schulz wrote:
Hi Ralph,
On 11/5/26 3:33 PM, Ralph Siemsen wrote:
I also agree that it is hard to detect the actual dependencies. And in
fact they are not static: when a reviewer of one series requests
changes, it can often impact other series. Which suggests that there
is a dependency, even if it was not apparent initially.
At some point, there's also "don't send too many series at once". If
your series A requires big changes in series B, it either means it
should be series A+B, or that series B was sent too early and we
should focus on answering design questions in series A before having a
look at series B. Sometimes patience pays off in the long run.
When adding a new SoC, we end up with series A+B and often many more.
All of that code needs to be written in order to get the device to boot,
so it is generally not possible to "upstream" any of it until it's all
functional. (I don't like to send out untested code!)
The problem then becomes, which series to send first. Inevitably, in at
least one of the series, a reviewer will suggest another approach,
perhaps to extend some existing subsystem, or simply to do certain
things a different way.
Unfortunately such suggestions frequently result in changes to the other
series. These changes are hard to anticipate or plan for. Sometimes I
try to send an early preview "RFC" to help identify such issues. But
even then, during the actual merge, further changes are requested, once
again with ripple effects on other series.
Sending out the series in a different order would not avoid this problem
in general. Specifically because it is hard to know which parts will
generate friction with reviewers. My guesses have been wrong more often
than not in this regard.
Not sure there is anything we can really do about it, but I can totally
understand why someone would send large "add new SoC xyz" patch series.
It keeps everything together and the ripple effect of one change can be
seen more clearly, than if all the pieces were done in separate series
over a longer time period, with goalposts being moved along the way.
Anyhow, I've posted v3, with a focus on making it easier for the
reviewers and the future code maintainer.
Regards,
Ralph
