Hi James,

On Tue, Aug 30, 2011 at 5:27 PM, James Wang <jwang....@gmail.com> wrote:

> Hi, Christian:
>
> more questions:
>
> Enable Search box is always disabled, with "Pylucene( with JCC ) is
> required to enable search. ' but i installed both already on this Ubuntu
> server.
>

Try restarting the server to make sure that that check wasn't just cached.
It very well may be that PyLucene wasn't installed in a place where RB could
see it, though. Make sure they're using the same Python version.


 Is there a way to configure an(or a list of) email address to be always in
> the CC of all outgoing messages from RB? or at BCC?
> so that he is invisible from the eamil recipients?
>

No. You'd have to modify Review Board to do this.



>  And I found RB does not check in the code when the reviewer click 'Ship
> It'.
>

It's not supposed to, nor could we guarantee that would work.

The requirements to check in code varies between various types of
repositories. We'd need the user's credentials, or maybe even a private SSH
key. We'd likely need a checkout of the code, per-user, which could
potentially be gigabytes each. We'd potentially conflict with their own
commit, which may span multiple commits (think Git) and have carefully
worded commit messages. And we'd need to somehow work with any other access
control policies or other restrictions set up on the repositories.

On top of that, we'd have to completely change how Ship It works. Who has
the final say about a Ship It? How many Ship-Its constitutes a check-in?
Does someone have more say than someone else? How do you handle that when
code touches parts of a codebase for which different teams are responsible?

Basically, it's not something we plan to do. Instead, we've chosen to keep
Review Board simple, make it a tool about reviewing code and other files,
and leaving the actual check-in process to the user, who is likely already
set up for this. We get to keep the product simpler, reduce the amount of
testing that has to be performed (thereby reducing the number of bugs), and
we don't enforce policy on Ship Its.



>  How does it possible to enforce a pre-commit review process so that
> reviewboard does the check-in after review process finished?  is there a
> hook on "ship it' or 'submitted' I have to configure?
>

I believe some companies may have custom code that intercepts a commit
before it happens, looks for a review request ID or URL in the commit
message, checks with Review Board to see if it had permission to ship, and
then decides whether to allow it. Again, that will vary greatly based on
repository type and policy, so we don't have anything we can provide for it
out of the box.

I find that it's more effective to handle this outside the tool. Make this
the policy in your organization. If people are committing code without
getting it sufficiently reviewed, talk to them, or their manager. Some
companies have pre-commit checks to look for a "Reviewed by" field
containing a list of usernames, which I think helps people to be more honest
about who actually reviewed it (and it's easy to call them out if there's no
proof those people did review it).

I know those aren't the answers you wanted, but I hope that helps in some
way.

Christian

-- 
Christian Hammond - chip...@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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to