Ok, let me clarify with a concrete scenario.
We use JIRA for our bug tracking. JIRA generates bug IDs such as
"BUG-123". We also have Hudson for continuous integration, and it's
tied to Perforce to poll for changes, build the changes, and log the
changelists in the build (for release notes). Our standard process is
to include within our Perforce descriptions the JIRA bug ID our check-
in is for, so Perforce syncs with JIRA to update the issue with the
Perforce files modified to complete the circle. So now we know what
files were changed to fix what bugs in which build (and in reverse,
what build certain changes were included in by reference through
There are many, many, MANY times where one check-in (and therefore,
one changelist) does not encompass all of the changes required to
resolve the bug, but all changes are tracked by a single JIRA. We
have a culture of checking-in often and not holding onto files for
days on end until we check-in one massive changelist since we're
developing in a highly collaborative and volatile environment (we
often have people developing within the same file at the same time, so
merges are often done on a daily basis). This is why we use CI to
build and test the project regularly. So it doesn't make sense for us
to create dozens of new review requests for new changelists since they
are often updates to a related JIRA.
Now, we're both in agreement that the CLI provides all the
functionality of creating and updating reviews and the developer can
decide what files update what reviews and when to create a new
review. However, I can't get my developers to use it. Both Kyle
Hayes and I have been expounding it, documenting it internally,
emailing our team, and we haven't had a single person use it yet. And
until I have something people will use (or even better, in their view,
is if it's done for them), I can't make it a standard.
So my goal is to create a Hudson plugin to link Perforce and
Reviewboard for post-commit reviews. Now, I know that Reviewboard has
a field for Bugs, which we currently have linked to JIRA, but I'm not
aware of a way to pass that in as part of post-review, or retrieve
through a CLI query, so I'm looking into mapping a Perforce
changelist, to a JIRA bug (via the bug ID entered in the changelist
description) and the Reviewboard ID. This mapping should be
relatively trivial. What isn't trivial is making updates to a review
request when an updated changelist is submit (meaning a second
changelist is submit with the same JIRA bug ID as another changelist
that has an open review request). This is where my Improvement
request 1562 would have been helpful.
>From what I gather in your post, however, is that "revision-range"
isn't supported by post-review for Perforce which shouldn't be a
problem. Hudson gives me the depot paths as part of the change set
the build was executed for. I just want to make sure that if I have 5
files in the review, and I add 2 and update 3 that the review shows 7
files with three deltas and the other 3 files that were in the
original review aren't dropped.
I hope that makes sense and isn't too confusing. I know post-commit
is a less-than-ideal solution. I'm pro-pre-commit, but my team is
not. Well, they're not even really pro-review, but that's going to
change, and I need to start somewhere. So, unless I make it easy or
transparent to them, they will keep pushing back. For the time-being,
some review is better than no review!
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
To unsubscribe, reply using "remove me" as the subject.