Thanks for clarifying Christian.
> "Submitted" basically means that the review process for this change is done,
> the code (or docs, or images, etc) has gone in, and no further work will be
> done on this particular review request or change. New work on the feature
> would then go into a new review request. By marking it as submitted, it
> won't clutter up people's dashboards anymore.
OK, that's why you can hide/unhide the "Submitted" reviews from the
dashboard. Is this the only way? Are you planning to provide some
sort of filtering?
> The only time I really see a submitted review request being reopened is when
> there's a build breakage and the change was reverted and must be updated
> again, but whether it's used this way or not is a personal thing. A
> developer could easily create a new review request for this purpose.
Its a little like a bug report being active or closed then. Would it
not be more intuitive to use the following state review states:
However, I imagine the frame of mind was that you wanted to indentify
the state of the "reviewed code" as opposed to the state of the
review. From that perspective, the source code is a "draft" at first,
it is "under review", and then, when all paries agred, the state
becomes "review completed".
> In a future version, I'm hoping we can make this a little more useful by
> specifying an optional message when closing as submitted (such as the change
> number/revision the change was committed in).
Have you considered broadening the scope of your work to provide a
framework for development workflow? The state of the code review
could then be used to drive some other tools or interact with some
other tools. For example, if a group wanted to set up a blocking
review system for instance, they could tie the (D)VCS with ReviewBoard
to prevent code from being checked-in/submitted/committed until the
review has been performed and the code accepted. ReviewBoard could
have another state ("Rejected" or something like that).
I happen to use reStructuredText for documenting purposes, and wrote a
simple system using Mercurial and Apache where each reSructuredText
file committed to a depot gets transformed into HTML and served by the
Web server. I was thinking I could even use ReviewBoard to review the
documentation that way. It might be nice to control whether the text
has been reviewed and accepted for publication or rejected until
The same ideas could be used for code. Code could be committed first,
then the automatic buidlers (pybots) would do their jobs, complie,
statically check, run unit test and if all is ok, would create a
review request for a human to go through (all the code, or some code
depending on the sensitivity of the code areas perhaps). The code
would only be allowed to move into another depot for incorporation
inside the product once the review was identified as a success. If
the reviewer(s) rejected the code for any reason, the code would not
be allowed into the product.
Just some more ideas...
You received this message because you are subscribed to the Google Groups
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at