Yep, post-review updates are important :) Our version at VMware was quite
stale for a long time too. We're probably due for an upgrade actually, but
maybe after the next release.

That's weird about the last updated time. Can't really think of what may
have happened there. Definitely odd that it's only one. Oh well..

Not sure exactly how old your 0.9 was (we had that version number for a
looooong time) but it probably is a lot faster. We beefed up caching,
simplified SQL queries, stored more data instead of computing it, and made
loading of diffs in the diff viewer asynchronous, so if you were missing any
of those, there should be a good speed improvement.


Christian Hammond -
Review Board -
VMware, Inc. -

On Thu, Oct 29, 2009 at 10:21 AM, Chris Clark <>wrote:

> Chris Clark wrote:
> > On Oct 29, 2:22 am, Christian Hammond <> wrote:
> >
> >> I should point out for anyone else reading the notes that you were able
> to
> >> get away with not needing the old secret key because you're (I'm
> assuming)
> >> using something like LDAP or NIS or Active Directory. In these cases, we
> >> don't store an encrypted password in the database, so it should be fine.
> >> However, if you have *any* built-in auth accounts (like an initially
> created
> >> admin user), you'll probably want to use your old secret key. Or just
> use it
> >> anyway, it should be safe enough.
> >>
> >
> > We're currently using built-in auth (we're hoping to move to LDAP/AD
> > soon as we already have AD setup for other stuff). Weird... I know!
> > Thought it was worth mentioning as it (potentially) saves a step.
> >
> > I didn't purge cookies, I did have to login using the regular login
> > form so I think the auth really is working (rather than cookie
> > caching). I'm guessing the per-password salt is stored in the database
> > along with the HMAC rather than using the site setting shared key (but
> > this is just a wild guess).
> >
> > I should point out that I'm not storing auth for SCM's (all the SCM's
> > we use do NOT use auth) which maybe where the shared key may be used.
> >
> > If I get burned by this later with other security stuff I'll report
> > back :-)
> >
> Follow up after a days usage after the upgrade.
> Not sure if I've been burned but cookies on client machines expired,
> which makes sense (the server did change).
> Some of my users had REALLY old postreview clients that had the "looping
> when auth fails" bug
> <>, which was
> fixed a while back.
> Moral of the story, make sure your users upgrade postreview when asked
> to :-)
> I did have one review that had a last_updated time in the future (some
> time in 2011) which meant that one review was constantly at the top of
> the review list with an "Updated 0 minutes ago" note on it. I didn't own
> the review so I ended up cheating and updating the record:
>    $ sudo rb-site manage /var/www/reviewboard shell
>    import datetime
>    from import ReviewRequest,
> ReviewRequestDraft, Screenshot
>    # review to update id is 405
>    x=ReviewRequest.objects.get(id=405)
>    mydate = datetime.datetime(2009, 05, 21, 19, 15, 0) # date it was
> submitted
>    x.last_updated = mydate
> Using SQL would have worked too.
> I've not done any benchmarking but the new release "feels" faster to me
> compared with 0.9.
> Chris
> > To unsubscribe from this group, send email to
> For more options, visit this group at
> -~----------~----~----~----~------~----~------~--~---

Want to help the Review Board project? Donate today at
Happy user? Let us know at
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to