RISC-V SoC Drivers for v6.2

[Arnd Bergmann]

On Tue, Nov 22, 2022, at 16:14, Conor Dooley wrote:
> On Tue, Nov 22, 2022 at 07:00:00AM -0800, Palmer Dabbelt wrote:
>> On Tue, 22 Nov 2022 06:38:40 PST (-0800), Arnd Bergmann wrote:
>> > On Mon, Nov 21, 2022, at 18:24, Conor Dooley wrote:
>> > - Splitting up a large pull request into smaller ones can be
>> >   helpful to make sure things don't go in unnoticed. I try to
>> >   (briefly) look at each patch, but if you have 20 boring but
>> >   large patches, and a small but important patch that I may
>> >   need to comment on, that is a good reason to split.
>
> Sure. I'll try to figure out what makes the most sense for a split
> versus having stuff in linux-next in a reasonable way. I suppose volume
> of changes will mainly dictate the approach.

Note that you can split things two ways, either by time or by
content: If you feel that the branch is getting a bit large,
then use that as a hint that you should send out parts early,
and follow up with another set of changes later, even if that touches
the same files. Here I would expect later pull requests to be smaller
than earlier ones for the same merge window.

Splitting by content is different: If you feel that something
in the branch is not like the other things, then you can split
it in a way that would give each branch a sensible tag
description rather than having to describe two different things
in a coherent way. Often this ends up with one of them being
much larger than the other, and that is ok.

      Arnd