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
- 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 <chip...@chipx86.com>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.
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at