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

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

On Thu, Nov 05, 2026 at 12:00:27PM +0100, Quentin Schulz wrote:
>
>On 11/4/26 8:48 PM, Ralph Siemsen wrote:
>>+Of course there are sometimes cases where a large patch series is 
>>okay:
>>+
>>+* when the changes are all in a specific area: for example when fixing a bug
>>+  in a driver, but also doing some refactoring or cleanup in the same code
>
>issue: This is typically the things we don't want to see I believe. 
>Separate bugs from refactoring, cleanup, and new features. The 
>argument is: we want the bug to be fixed as soon as possible, but we 
>*reaaaaally* like to merge full series at once, so having this kind of 
>changes mixed in a series means it's likely we'll either ask the 
>contributor to split the series, or if the non-bug-fixing part of the 
>series is controversial or not in a good state yet, unnecessarily 
>postpone the merging of the bug fix.

Maybe I should have said: "*directly related* refactoring or cleanup"?

Ideally a bug fix should be its own patch, and certainly it should not 
include any new features. But sometimes a bit of refactor/cleanup helps 
to make a bug fix easier to implement and/or understand.

>>+* when there are unavoidable dependencies between patches: keeping them
>>+  together avoids having to explain how multiple series are dependent
>
>thought: People usually struggle to detect the *actual* dependencies 
>and are usually leaning too much on "I need those two drivers to be 
>merged for the board to work" for example. We've seen this more 
>recently with a full SoC bring-up being sent as one series. Yes, the 
>SoC is unusable without all the minimally required drivers, but each 
>individual driver can and should be sent a separate series. I'm not 
>sure how we can word this better, maybe providing a real-life example 
>would be nice. This can always be improved later on, so not a blocker.

Having struggled with this myself, while I do agree with the idea of 
using separate series, it does complicate the development process. It 
means a branch for each series, and merging them together for each 
compile/test cycle. Only after doing this dozens of times did I realize 
that I could stack the branches on top of each other rather than merging 
each time. Then "git history fixup" and "git history reword" made it 
much easier to modify the stack. But all of this has to be learned and 
it is not immediately obvious.

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.

>With the issue in the previous paragraph fixed, I think this is a good 
>improvement and we should merge as soon as possible.

Perhaps I should just drop the whole "Of course there are sometimes 
cases where a large patch series..." section?

Regards,
Ralph