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
