On Tue, Jun 4, 2013 at 1:47 PM, Stephen Gallagher <step...@gallagherhome.com
> On 06/04/2013 05:47 AM, Christian Hammond wrote:
> > On Jun 4, 2013, at 2:44 AM, Stephen Gallagher <step...@gallagherhome.com
> > <mailto:step...@gallagherhome.com>> wrote:
> >> On Tuesday, June 4, 2013, pfee wrote:
> >> Hi Christian, Stephen,
> >> While testing Stephen's Fedora packages, on a F18 machine I
> >> upgraded from 126.96.36.199 to 1.7.9. Following the upgrade, I expected
> >> visiting the site's /dashboard URL would have told me to run
> >> "rb-site upgrade". Instead I got a 500 "Something broke..."
> >> Despite not being prompted, I ran "rb-site upgrade
> >> /var/www/reviewboard" anyway. The site came back to life and
> >> started working again as expected, however someone upgrading for
> >> the first time would not know to do this.
> >> Ah, thanks for reminding me. Not that anyone actually reads the
> >> updates notes, but I usually put a reminder in that you always need to
> >> run rb-site upgrade after installing the packages. I'll tweak the
> >> update notes when I get to work.
> >> I've been meaning to patch the Fedora packages to do this
> >> automatically, by having rb-site install save a config file with a
> >> list of installed sites so I can have the %post script run the upgrade
> >> on package install.
> > I've actually been wanting such a file for Review Board upstream that
> > rb-site can write to, so that we can be more intelligent about upgrades.
> > If you come up with a good way to do it, let me know :)
> Has Review Board formally and without question dropped Windows support?
> If so, it becomes reasonably easy to hardcode a requirement on a file
> such as /etc/ReviewBoard/sites which could be as simple as
> one-path-per-line, and then patch rb-site to amend it when doing an
> install and to iterate through it when calling 'rb-site upgrade' with no
> Then all I would have to do in the Fedora packages is call 'rb-site
> upgrade' in the %post section on upgrades.
Just a comment from BitNami. Even if Windows is not supported it would be
great you don't have any path hardcoded. Currently we allow to have
different installations in the systems in different installation paths,
installing as root as an not root user. Of course this is also possible
without using the BitNami installers. Having that hardcoded will affect
this flexibility. If those are necessary I would suggest to have default
values..but not hardcoded and not customizables values.
> 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
> You received this message because you are subscribed to the Google Groups
> "reviewboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
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
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.