FAQ additions and (probably) dumb questions

[Chris]

I've been playing with RB the last week or so and I'm really
impressed. The syntax highlight for diffs is awesome!

I've added (as a comment to the end) a couple of additions to
http://code.google.com/p/reviewboard/wiki/FAQ
Hopefully they will be helpful, they are basically things I hit and
then found in the mailing list/group.

Now for the dumb questions :-)

Is there any value in me posting a review with a patch that adds
revision numbers to the file list in diff view? I know the revision is
in the diff (under each file name) but with source code systems where
each file may have a version, seeing the rev in the files changes list
is (IMHO) handy.

Once a review has been "set submitted", is there the concept of
finding the change number that fixed it? The only way I can see is
ensuring a bug tracker is used than clicking through to that. Do other
people edit the review with the change number before "set submitted"
or is this not something anyone has a need for?

Last one, the emails that get sent out for review on my system end up
having extra slash in the url after the domain:port, e.g.:

http://MYBOX:8000//r/55/

so the url doesn't work, is anyone else seeing this or is this a
misconfiguration on my part? I've tried setting the domain with and
without a trailing slash (initially I set it WITH a slash, maybe this
caused it).

Thanks!

Chris

[Christian Hammond]

Hi Chris.

Answers below.

On Mon, Oct 6, 2008 at 5:12 PM, Chris <Chris...@ingres.com> wrote:

I've been playing with RB the last week or so and I'm really
impressed. The syntax highlight for diffs is awesome!

Glad you like it!
 

I've added (as a comment to the end) a couple of additions to
http://code.google.com/p/reviewboard/wiki/FAQ
Hopefully they will be helpful, they are basically things I hit and
then found in the mailing list/group.

Thanks for the FAQ entries! I'll incorporate them into the main FAQ when I get some time to do so.
 

Now for the dumb questions :-)

Is there any value in me posting a review with a patch that adds
revision numbers to the file list in diff view? I know the revision is
in the diff (under each file name) but with source code systems where
each file may have a version, seeing the rev in the files changes list
is (IMHO) handy.

I wouldn't be opposed to this, though revisions get quite large for some systems (think Git, Mercurial, etc. which use SHA1 values for revision information). We'd need to figure out something clever there.

 

Once a review has been "set submitted", is there the concept of
finding the change number that fixed it? The only way I can see is
ensuring a bug tracker is used than clicking through to that. Do other
people edit the review with the change number before "set submitted"
or is this not something anyone has a need for?

This is highly dependent on the version control system and we'd need a hook script that updated Review Board, along with a way to tell the hook script which review request had the submitted diff.

Take SVN, for example. There's no standard way of passing along such metadata and rarely do people use standard templates of any sort for SVN commit messages. However, someone could require a certain format for specifying the review request ID, have a hook script that then updated the review request, and then things would work. It'd be very non-standard, though.

In the case of something like Perforce, companies tend to have changeset description templates, and one could provide a field for the ID. Again, there would need to be a hook script that handled updating the review request.

Another option would be to require a wrapper around svn, p4, or whatever tool is being used which did this work.

Once that's figured out we'd need to figure out how best to update the review request with this new information. Post-1.0, we could provide a field indicating which revision the code was committed in, and then provide API for scripts to set this. At the moment we don't have much of anything for this, though, but if someone wanted to write it we'd take it, and it would probably be fairly easy.
 

Last one, the emails that get sent out for review on my system end up
having extra slash in the url after the domain:port, e.g.:

   http://MYBOX:8000//r/55/

so the url doesn't work, is anyone else seeing this or is this a
misconfiguration on my part? I've tried setting the domain with and
without a trailing slash (initially I set it WITH a slash, maybe this
caused it).

I think this is due to bug 640 (http://code.google.com/p/reviewboard/issues/detail?id=640), which I'll try to look into tonight.
 
Christian

--
Christian Hammond - chi...@chipx86.com
VMware, Inc.

[Chris Clark]

On Oct 6, 5:39 pm, "Christian Hammond" <chip...@chipx86.com> wrote:
....

> > Once a review has been "set submitted", is there the concept of
> > finding the change number that fixed it? The only way I can see is
> > ensuring a bug tracker is used than clicking through to that. Do other
> > people edit the review with the change number before "set submitted"
> > or is this not something anyone has a need for?
>
> This is highly dependent on the version control system and we'd need a hook
> script that updated Review Board, along with a way to tell the hook script
> which review request had the submitted diff.
>

.....

>
> Once that's figured out we'd need to figure out how best to update the
> review request with this new information. Post-1.0, we could provide a field
> indicating which revision the code was committed in, and then provide API
> for scripts to set this. At the moment we don't have much of anything for
> this, though, but if someone wanted to write it we'd take it, and it would
> probably be fairly easy.

...

I guess there are two parts to this:

1) How do I get a change set id (manually) attached to a submitted
review
2) How do I get my SCM submission to update ReviewBoard automatically?

I was thinking of #1 above and based on your comments this is
something that is considered a post 1.0 feature. This maybe something
I can look into, at the moment this is fairly low on my list of needs
(top of my list is the integration a plugin to ReviewBoard for our
bespoke SCM).

#2 probably falls on to the bug tracking system (if there is one). So
long as we have an api (I suspect there is one) to set a review as
submitted this isn't Review Board's problem. Looks like I maybe doing
some integration with our bug system too :-)

> I think this is due to bug 640 (http://code.google.com/p/reviewboard/issues/detail?id=640), which I'll try
> to look into tonight.

I appreciate you taking the time to respond!

Chris