On Mon, Aug 22, 2005 at 07:36:40PM -0700, Jon Phillips wrote:
UPDATE!
So, sf.net is completely unsecure now for the web server to write data. So, I have a solution to move the wiki to fd.o and make it work there temporarily.
Unfortunately, we are coming to the limits of using sf.net. We need to start thinking about where to move our project, as it is getting quite large and sf.net is too slow, not reliable for real world web-based needs, and we want svn.
http://inkscape.org/cgi-bin/wiki.pl?ChangingCvsProviders
I will ping the list once the wiki change has happened.
Jon and I talked a bit about this yesterday; I mentioned that given our desire for svn (and sf failing to provide it for so long), this issue with the wiki, and the various other issues we've run into, that maybe Inkscape's needs are growing beyond what SourceForge can provide.
Personally, I think right now may not be the best time to make changes in how Inkscape's project infrastructure works, since people are fairly busy, but it may be worth thinking it out.
I'd done a DIY infrastructure in a previous big oss project I ran, and found that while you can do it, it sucks attentions away from the core project. As well, it can create some tension between users who want perfect service, and the sysadmins who want users to not whine. ;-) One of the major reasons why I had Inkscape stick so firmly to SourceForge early on was so that we as a project could focus all of our attention on the code, rather than on mail services, apache, version control, etc. etc.
A possibility is to switch to another third party provider, such as Tigris, Savannah, etc. This could be the best solution, as it may give good capabilities with little work on our part. A risk is that we could be exchanging one set of problems for another. It's worth checking out, though.
However, it's possible we've grown as a project to a point where we *could* take care of providing some or all of our own services. Our needs are becoming increasingly more specific, and our desire to be able to customize things sort of goes beyond what can be done via sourceforge. Going forward I think it's quite likely we are going to need to handle at least some services ourselves. I think as long as we go about it in an organized, pro-active manner, (and can afford the bandwidth) we can get really good results for ourselves.
In WorldForge, we ran our own mailing lists, irc server, CVS, and web. Some lessons I learned in setting this up:
* Never set up a DIY service without including remote backup to at least two other project people that can run the service. If you don't do this, half of your administrative time will be spent recovering from all sorts of misc. disasters.
* Set up a central account system. If for each service you allow it to handle its own account management stuff, then the other half of your time will be spent sorting out account issues. ;-)
* It seems to work well if the sysadmin is not involved in the project. Seems counter-intuitive, but note how solid Inkscape's Jabber service is for us, and its sysadmin is otherwise not involved in Inkscape. Not sure why this is.
* There are more people who have bandwidth to share than there are people who have bandwidth *and* can afford the time to administer machines. The options are most open if you can handle these things independently.
* Shared ownership of a machine seems to work okay in practice. WF pooled money and bought a server, got it configured, and shipped it to the guy that had the bandwidth to host it; we then had multiple people with admin accounts. I think we could do this, too.
* Stay organized. Keep a master services chart listing all the services, who hosts them, who administers them, and who has backups. Otherwise, minor problems become complicated to solve, and major ones can put the project offline.
Bryce