On Mon, Jan 26, 2009 at 3:23 AM, Sebastian Kurfuerst <
sebastian.kurfue...@gmail.com> wrote:

> Hey Christian,
> thanks for your super-fast response!
> > Right now, we don't have anything in the code to enforce policies such as
> > requiring two "ship its" before you can close out a review request. Since
> > Review Board doesn't actually commit reviews, we can't enforce anything
> like
> > that.
> Yep, that was a slight misunderstanding. We neither need such a policy
> to _enforce_ something.

It's a common request so I thought I'd spend a minute going into that :)

> When you talk about a global "status" for a review, what exactly do you
> > mean? Can you describe how this would best work for you?
> OK. Currently, we have a mailing list for posting patches to, and as
> said, we require two "+1"s - at least one from a core developer. Now,
> many patches are still "lying around" as it sometimes takes a lot of
> time to review complicated changes.
> Currently, it is basically impossible to get a list of issues which
> still need one review - or a list of issues which are ready to commit.
> What I mean with "global status":
> - In a basic version, it would be nice to display the summed-up
> ranking of a feature in the summary of the feature - and as a column
> in the overview.
> So, if a feature has 3 times "Ship it", it should display "+3" (or
> something similar).
> - In an advanced version, it'd be nice to implement own strategies (as
> a Python module f.e.) for calculation of this "Status" value - so I
> could have a strategy which also implements the above-described
> policy.

As Paul Scott mentioned, you could write something to do some of this now,
but you'd have to write custom code to use the API.

Another feature planned after 1.0 is support for custom third-party
extensions, so in time you'd be able to make such a thing part of Review
Board while keeping it specific to your setup.

> > > - Is it possible to have a default "diff base path" depending on which
> > > repository you select? (We require all diffs to be made from a certain
> > > directory). Thus, our "diff base path" is in most cases /.
> >
> > We certainly could use a better default. There is none right now.
> OK - I'd just need to add this default in the Models.py, right? Or
> would you make it configurable?

You'd modify diffviewer/forms.py (maybe reviews/forms.py) to add a default
for the base diff path.

Doing it properly means a few things:

1) Adding a per-repository default, which means a new field in

2) Add a field to DiffSet in diffviewer/models.py for specifying what the
base diff path was for that upload, and then re-using it the next time the
user goes to upload something.

> > - Is it possible to have default reviewers selected depending on the
> > > Repository selected?
> > Sort of. We have support for default reviewers for file paths, but
> they're
> > global across repositories. We could expand this for the next release,
> > unless someone wants to do the work for this one.
> I could again do that, but I am quite unfamiliar with Python - so I
> doubt I'd get it right in the first place.
> Essentially, it would be enough to have a second field which is called
> "Repository RegEx", which is checked as well if non-empty.
> Right?

We'd need a ManyToManyField in reviews/models.py for DefaultReviewer. A
particular DefaultReviewer should be able to be configured with one or more
repositories that way. Then we'd just need to check the repositories in the
code that uses DefaultReviewer.

> Review Board's pretty much a part-time project of David Trowbridge and
> mine,
> > and we're in general quite busy, with a large to-do list, so I can't
> promise
> > we'll get to all of those right away. Many people who use Review Board
> and
> > need new behavior contribute patches, which is the fastest way to get
> such
> > things in the code base. I should also point out that we're entering a
> > feature-freeze period soon for our 1.0 release, so we'll soon start
> pushing
> > new features back.
> Yep. When do you enter it? It'd be nice if some stuff (like the
> summation of "Ship it") could already enter trunk :-)

We won't be able to get that in for 1.0. We're entering freeze within a week
or two, I imagine. There's a few key things we're going to try to get in,
but the Ship It stuff is going to require more thought and time than I feel
comfortable doing right now.


You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to