[Skip Montanaro] >> Is it time to think seriously about moving away from SourceForge? [Martin v. L=F6wis] > Any proposal to move away from SourceForge should include a proposa= l > where to move *to*. I highly admire SourceForge operators for their > quality of service, and challenge anybody to provide the same quali= ty > service. Be prepared to find yourself in a full-time job if you wan= t > to take over. I'm not sure that better alternatives for *some* of what SF does coul= dn't be gotten with reasonable effort. For example, on a quiet machine, I ju= st did a cvs up on a fully up-to-date Python, via SF. That took 147 seconds= . I also did a cvs up on a fully up-to-date Zope3, via Zope Corp's CVS se= tup. That took 9 seconds. I expect at least as many (probably more) peopl= e hit Zope's CVS as hit Python's CVS, and ZC appears to put minimal effort = into maintaining its public CVS servers. A crucial difference is that SF = CVS has to serve hundreds of thousands of people, and ZC's more like just hun= dreds. > SourceForge performance was *much* worse in the past, and we didn't > consider moving away, and SF fixed it by buying new hardware. Give > them some time. There have been times over the past few weeks when cvsup time via SF = was as bad as it's ever been, meaning > half an hour to finish. There have = also been times when it's been quite zippy. I think they've made tremendo= us strides in cutting response time for the trackers, though (that was i= ndeed very much worse in the past).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4