Modernize the Manual Updates pages and add more useful checks and instructions
Review Request #2434 — Created June 25, 2011 and submitted — Latest diff uploaded
The Manual Updates pages were written back when Review Board was still installed through an SVN checkout and custom configuration files. They're more confusing than anything these days. This change fixes that. First, the pages look less ugly now. The text is more readable, and there are page headers and margins. The gold box with the initial instructions no longer points people to an old wiki page, and we don't talk about "recent changes" but rather "upgrades." The very misleading page talking about syncdb has been removed. People would hit that with all sorts of database errors, and our instructions were almost always wrong. The page was originally written to catch the case where people upgraded, got the "new" ChangeDescription model, and would later on crash when something tried to access it. Even worse, it would talk about running "./manage.py." Not only should people use rb-site, but "./manage.py" isn't even correct in a source install anymore. What we have now is an initial query for a SiteConfiguration. If it fails for any reason, we display a page saying there may be a database error. We give some useful hints and then show them the database error. It should tell them if tables are missing, if there are connection issues, or if the database is locked. This will of course be database-specific. We now check the running version and compare it with the last stored version from the previous site install/upgrade. If they don't match, we tell the user and give them instructions on fixing it. The page knows if it's a developer checkout vs. production install, and gives the appropriate command lines to fix the problem. On developer installs, we will hit this after version bumps, until we do a syncdb. The data directory is another problem area for people. We try to give instructions at the end of rb-site install/upgrade, but people don't always read them. Now we check for the directory's existence and whether it's writable. If the directory isn't what we expect, we tell them (helping in the case of $HOME pointing to something like /var/www). We give instructions on fixing $HOME on Apache, fastcgi, and wsgi. And we give instructions on fixing permission problems. All paths and usernames are picked up from the system, and should in most cases be correct.
Tested each of these on a developer install and a site install, with each combination of problems.