24hour code reviews: still aiming for it

I mainly review code written by team perf. You’d think a 6 person team would imply a fairly chill review queue. The team must’ve conspired to burn me out, for a few weeks I was spending half of my day reviewing patches. A few patches took >3 days to review. I think I even let a patch lapse for almost a week (don’t always have mental capacity to review linker code). Recently, my review inbox is often empty and recent patches have been <10KB, I’m not falling behind anymore.

My point is that 24hour reviews are not bounded by time. It’s an aspirational target. If you value time spent writing the patch, please review accordingly. Same goes for people requesting reviews, I’m a lot more likely to give you a quick review if your patches are broken up into reasonably small logical pieces.

The 24hour-review-turn-around dream is still alive. I haven’t been making noise about it because I’m waiting on #metrics to provide us with hard review-latency data. I’m hoping my review turn-around is 24hours, but there is no easy way to find out atm.

Thanks to everyone who adopted 24-hour review goal. I have noticed reviews flying by at a faster pace. One reviewer even let a team-perf patch jump to the front of his review in return for pushing on 24hour reviews.

2 comments

  1. Gavin gave me a great tip — join #bugs and let firebot’s announcements of bug activity trigger a hilight for your bugzilla email.

    Right after doing this, I happened to have a patch come in and reviewed it in < 30 minutes. Would have been faster if I wasn't doing other things. :)

  2. Your posts on 24 hour reviews have motivated me and I’m sure many others on moving faster on reviews. Thanks for pushing for this.