We have a pretty good code review process, but there are couple of issues. The most annoying problem is merging. From time to time the number of stuff to merge grows rapidly and some of the commits are getting old. As a result, rebasing is a pain (conflicts).

What can we do to avoid it? I can think of two possible solutions:

  • Merging Thursday. From 10 to 12 every week we merge PRs
  • Have a timeout on PR. If it's in peer review for a week, spam everybody in the team.
  • 3
    Why does it take so long to review a PR/commit? You should look for ways to solve that (organizational) issue. – Bart van Ingen Schenau Jan 7 '15 at 11:40
  • Not sure, possibly because it's not pleasant task. – Lukasz Madon Jan 7 '15 at 16:24

A somewhat excessive solution is to prevent your developers from committing, while they have reviews to do.

But as Bart writes, it is really an organisational issue, an you ought to solve it by reminding the developers that reviewing has a higher priority than writing new code. Some developers might like to have a tool giving a "live" indication of how many reviews they have in their queue.

I don't know how you organise reviews in your group, but if you don't assign specific reviews to specific developers, that may lead to everybody hoping that somebody else will do the work.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.