> I don't think it is a good idea to move services to Savannah while it > is already a loaded computer.
We must have different definitions for loaded. Savannah's load is trivial, considering it's a quad Xeon. Over the last year, measured by our cacti instance, the 5 minute load average is < 2.0. Over the last few months, that drops to 0.96. In addition, iostat seems to suggest that the disk subsystem is under 10% utilization. And with over 1gb of ram inactive it's not pressed for memory. Not only that, but nongnu.org is static web content. It is unlikely that the addition of this would have any noticeable effect on Savannah's performance profile at all. I don't want to press the issue. If you don't want to do this, or don't see the utility in it, it can simply stay where it is now, and everyone agrees that the current system needs to be improved. > Note that nongnu.org is quite simple since all accounts are dealt with > the same way (nongnu.org/* and *.nongnu.org). Agreed. > gnu.org however is much more complicated because every project may be > replicated at a different point of the hierarchy (software/, /, > translation projects, education/, and other exceptions). > gnu.org is probably where improvements are needed the most. What improvements, in your mind, should be made? There are a number of potential improvements that come to my mind... As for what has been done, all the scripts involved in the process (cron jobs, new project creation script) now do comprehensive logging and check to make sure that they are not stomping on each other (the latter was an improvement made a long while ago). Debugging any problems should be much easier. Indeed, several were exclusively related to the migration to Apache 2.0, and shouldn't reoccur. One thing I noticed is that scripts that are called from Savannah return nothing in the way of output. A possibility is to actually return a status code and message - either that, or an XMLRPC interface to replace the given system could be designed, which would actually return any useful information including error messages, and also allow a variety of useful operations (re-checkout a project from scratch, make a new project, update a project, etc). There's no real reason on our end why we can't do on-commit updating now. I'm willing to spend the time getting it done, along with any other improvements you want made. -Justin -- Justin Baugh (baughj at gnu dot org) Systems Administrator Free Software Foundation
