Re: [PATCH v2] doc: develop/sending_patches: add tips for series

[Ralph Siemsen <ralph.siemsen@linaro.org>]

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