Is Tracking possible in Review Board?

[sakthi]

I finally made ReviewBoard up. I wish to know whether the following
things are possible in Review Board,

I tested the Review Board like this,

Step 1: I changed a file which is already in repository and checked
in.
Step 2: Posted the change (diff between current and previous
version)into ReviewBoard.
Step 3: Reviewed, added comments, and publish it
Step 4: Modified the code with respect to comments and checked in.
Step 5: Posted again into the same review-request-id
Step 6: Can see the diff between reviewed version and current version

Now, is there a way to map the earlier comments with the code change?
is it possible to track the comments given in a version with future
versions
Is it possible to see a summary of comments?

I think it would be nice to see summary of comments and classify as a
"bug" or "not a bug" etc
also classify user as reviewer or review leader etc

After a week long struggle in installation, now i feel simple XL is
better to track the review comments than using Review Board ! or am i
missing something?

Regards
Sakthi

[Christian Hammond]

Hi,

To answer your first question, no, there is no way to map the existing comments to your new changes. This has come up a couple times over the last couple years, so hopefully I can explain the reasoning well enough.

Comments are tied to line numbers in per-file diffs. This is the line or row number of the side-by-side diff, a union of the two files, rather than being the actual line of an actual file. The reason it's like this is because that comment applies to the change being made in that side-by-side diff view. It may be a comment about a new line that was added, a line that was removed, or about explicit changes in a line.

What this means is that the comment is very much tied to that particular set of changes. If a new diff is uploaded, it's certainly possible that some of the changes and lines would match up, but in order to match them and carry the old comments over, we'd have to:

1) Re-parse the old diff (which may involve downloading the files from the repository again and re-patching, which can be time-consuming)
2) Build the side-by-side diff internally
3) Find the lines in the diff that the comment spans
4) Go through the new diff and try to find lines that match it (remember that the line numbers may not match, so we actually need to look through the diff, which is slow and may find similar but wrong lines)

Now, even doing that, we'll only get *some* of the comments, since more often than not, there will be changes made that prevent old comments from being carried over.

Some may argue that this is okay, and that having some comments and not others is fine. However, this may lose context in the flow of the comments, and that could lead to confusion.

In short, carrying over comments to a new diff isn't planned and likely will never happen.

Now, as for a summary of comments, this is really what the review request page is for. You can see all the old comments and see the lines they pertain to. Granted, this is on the older diff, but if you combine this with doing an interdiff between the older diff and the newly uploaded one, you should be able to get a good sense of what's fixed and what isn't.

There are some plans to add a basic form of defect tracking. Being able to mark a comment as a defect that must be fixed. The developer of the patch would see the defects and could mark each as fixed. These will *not* tie into your bug tracker. They're just a part of the review process. We don't have this implemented yet, and will need to sort out parts of it, but it'll probably happen in a release or two.

Distinctions between "reviewer" and "review leader" and stuff is very much a company-specific thing. I'd be interested in hearing what you need for this. Keep in mind though that anything we're likely to do there will be insufficient for other companies. Some may want specific capabilities for certain type of people. We are looking at policy support for a future version, which will allow admins to limit access to certain things or grant permissions, but it's really intended for allowing a single Review Board server to be used for different groups who may not all have permission to see the same codebases.

I'm sorry you've had problems with the installation and that the workflow isn't what you're used to. Review Board's workflow works just fine for many people, but isn't guaranteed to be perfect for what you're used to.

Christian

--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com

--
Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to reviewboard...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en