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: - draft - active - closed 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 furher modified. 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... Pierre --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to firstname.lastname@example.org To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---