[gregkh]

Off the top of my head, no.

The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down problems, better development cycle as feedback can be more specific, easier evolution of changes, etc.)

I wrote a whole chapter in the book "Beautiful Code" about how this development model can help create an end result that is almost always better than the initial "huge" submission model. Check it out if you are interested, it should be free online somewhere...

[_xrjp]

I found it, Greg's chapter `The Linux Kernel Driver Model: The Benefits of Working Together` on page 267

- https://www.oreilly.com/library/view/beautiful-code/97805965...

- https://github.com/stormtrooper96/books/blob/master/software...

So I'll definitely give it a read. Thanks!

[600frogs]

My instinct would have been that it's easier for the submitter (as they have less to polish and test) and more irksome for the reviewer as they have to go through multiple rounds of submissions, but naturally I'll take your word for it!

This kind of discussion is always of interest to me, I'll check out the book, thank you.

[Filligree]

Reviewing three changelists, which individually do only a single thing each, is in my experience much easier than reviewing a single changelist bundling the changes from all three.

This is true even if the same lines are changed multiple times. It's something you'll learn with experience, but it's also not even close. Break your patches up as much as possible, and everyone will be happier.