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
long 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
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Thu, Oct 29, 2009 at 10:21 AM, Chris Clark chris.cl...@ingres.comwrote:
Chris Clark wrote:
On Oct 29, 2:22 am, Christian Hammond chip...@chipx86.com 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
http://code.google.com/p/reviewboard/issues/detail?id=808, 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 reviewboard.reviews.models 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
x.save()
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
reviewboard+unsubscr...@googlegroups.comreviewboard%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/reviewboard?hl=en
-~--~~~~--~~--~--~---
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
