I agree with you as well. However, when someone does publish a massive
review, I have no recourse.

Here are some suggestions (and only suggestions, meant only to get some
conversation going):

-  allow me to put a comment at a file level (i.e. not on a line number
within the file). I can use that to indicate "OK".
-  allow me to put a status on a file. A status is just an "ok/not ok"
indication, no text can be entered. Then allow the file status to cross
revisions, i.e. whenever I view any revision, I get a complete list of files
from all revisions. The only diffs I see are for the current revision, but I
can see all statuses for all files.
- allow me to put a status on a file, plus have RB keep track of the total
number of comments for that file across all revisions.
- have a status (ok/not ok) at the file level, one for each revieiwer.
Initially the status is "not ok". A new comment on any revision  for that
file resets the file status to "not ok". All reviewers can then go in, look
at the new comment and/or code fix, and reset the status (for them) to "ok".
-  allow me to remove a diff/file from the current review.
-  allow me to move a diff/file to another, new, review.
- give me full GUI support for splitting up an existing review (whatever
that means! :)

Are any of these easy to implement given the current RB architecture?


On Thu, Aug 26, 2010 at 2:34 AM, Christian Hammond <>wrote:

> I'll second this. It really is beneficial to try to break up the changes
> more. Preferably into logical changes (such as code to implement one part of
> the functionality rather than an entire feature, or doing code cleanups in a
> separate change), though if you're past the point where that makes sense,
> even breaking it up into file paths (potentially based on who is most
> familiar with certain groups of files) would probably help.
> I've seen this a lot too, where really large changes of mine have sat
> around because they're too long to review. Not only do people avoid them
> initially (since it requires such a time commitment), but the feedback isn't
> as good as it could be. Smaller changes receive better review and can get
> into the product sooner.
> Christian

Want to help the Review Board project? Donate today at
Happy user? Let us know at
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to