| Two top-level scenarios here: * you're working on the same part of the code * you aren't working on the same part of the code The second scenario is common but also trivial here since you can just have parallel branches going, so I'm gonna assume more the first - working on something that's building on top of what you just put up for review. Let's say the review is done in 2 hours. If you're already done with the followup, IMO you may be erring too far on the side of "small PRs." If you aren't, you just rebase on top of whatever changes had to be made, if any, to the first one, once it lands on the primary branch. If, on the other hand, the review isn't done for 2 days... then that's a PR turnaround time problem for sure. But I strongly disagree with the people saying "multiple dependent PRs suggests the work wasn't split up properly" - there's nothing worse than a mega-PR of thousands of lines for the sake of doing a "single feature" all in one shot vs having to possibly pause and rebase periodically after review. It's even more painful when this mega-PR requires fundamental changes that could've been caught earlier, but now will take longer to adjust, and then will stay open for a while and likely result in merge conflicts as a result. |
One of the projects I work on is a large, well-known open source project. Reviews that take days are pretty common.
> If you're already done with the followup, IMO you may be erring too far on the side of "small PRs."
There have been times when I created a sequence of three or four separate commits within under half an hour.
This was on projects where test coverage is tricky (think hardware interfaces) and keeping changes small was motivated a lot by better bisectability.
Clearly, software development is a pretty broad field with lots of different experiences.