Sometimes, we are asked to support a new service, for example a new SCM.

It can be argued that installing a new service is a matter of minutes. There are several problems with this:

  • even if we are small compared to other SCM hosting providers, we host around 2500 projects. Such an amount makes you meet limits that you never reach when managing a few dozen of projects. For example, some users are part numerous Savannah projects; in this case, the Debian glibc package prevents users from belonging to more than 32 groups (16 Savannah projects). You need to patch the glibc to overcome this. Another issue is the load: it's not difficult to setup a single CVS repository; when you serve a lot of repositories, you need to make CVS write temporary files to RAM fs. You also need to automate the creation of the service, which involves contributing code to Savane - and test it extensively! So installing a new service requires much time and tests.
  • any new service needs to be monitored, namely for security vulnerabilities. When a service is stable, distros can provide packages with automated solutions, which saves a lot of time. If there's not such a solution, that monitoring work needs to be done by the Savannah admins - and we do not have that much time :) If you want Savannah to support a new service and are willing to help maintain that service, regularly and in the long run, then that would fix that issue.
  • some services require more resources than others. A service may work perfectly for a single repository, but may not scale :/

Hopefully this will explain why adding a new service is not that simple.

Do not take this literally though - Savannah probably can be improved to be more reactive, provide "experimental" areas, and get more contributing hackers with different experiences and views.