Tell us how you deal with merge requests and code rot

Question

Only asking about work environment, not personal projects or OSS. On average, how much time passes between creating a pull/merge request and merging it in your organization? Do you make any conscious effort to keep this timeframe small? How often do you have to deal with stale merge requests? Is the merged code always shipped in the next release/deployment or not? Do you employ any specific techniques on increasing PR/MR throughput (amount of code changes merged) without compromising quality of the final product? Do you think automated test coverage is absolutely critical in this context or it might be possible to improve/optimize while not having a lot of automated tests and relying more on manual QA?

gregjor · Accepted Answer

I review PRs daily, usually 3 or 4 but sometimes more. They either get approved and merged/deployed immediately or sent back for re-work. No stale PRs: a pull request should be ready to merge.
I strongly encourage the programmers to submit small PRs so they are building incrementally rather than changing a lot of files at once. That keeps reviewing and testing easy.
None of the projects I work on use formal or strict TDD. I think it’s important to have multiple pairs of eyes reviewing the code.