Infrastructure Problems
Contents
Developers Only
This article is about collab.net from a developers perspective; if you are not a developer - it would be appreciated if you do not edit it. We aim to be factually correct, if this is not the case please add comments. It should be stated at the outset that no-one editing this has any commercial advantage from criticising collab.net beyond of course improving the OO.o situation.
It is hoped that as these issues are fixed this page will eventually become a glowing testimonial to the success & efficiency of collab.net.
Overview
The OpenOffice.org 'community' is a failing community. It resembles the 'Freedows' community of the early days - ie. a public joke - full of people talking, structures, project-leads, roles but only a tiny fraction of the people involved, accounting for a handful or two are developers.
As such I view collab.net's attempts to build a meaningful developer community as a near complete failure. The blame for this is clearly split between Sun & collab.net in a way that is hard to partition. This document merely aims to explore some of the collab.net specific problems. Other common problems faced by people are enumerated here
Collab.net services
Source Cast
This is perhaps one of the most annoying pieces of software I've worked with in a long time. Most OO.o services are provided by a single instance of SourceCast, running on 1 (Solaris) machine. It is not clear that this is an advert for the performance of Solaris - however, it is clear that some persistantly silly mis-configurations lurk there.
SourceCast provided services are typically extremely unresponsive - it typically taking longer to log-into SourceCast than search the entire-web at google.com with some complex search. High latencies are also sporadic - there are unpredictable periods of low & high latency.
Scaling issues
Under heavy load - such as close to a release - it is common for SourceCast to become almost totally unresponsive & unusable, sometimes for days.
Constant re-login
The 31337 ultra-secure TM SourceCast login infrastructure requires that you re-log-in very frequently. It's hard to quantify quite how frequently, but normally for every new bug filed it is necessary to go to the IssueZilla page, log-in, hit back, hit refresh - adding (if you're lucky) 15seconds or so to any bug filing - prolly more. This latency is not present with other bugzilla derived products.
CVS
CVS is extremely slow. This problem is compounded by the OO.o source code being extremely large it is true. However an order of magnitude slow-down is due to a simple source-cast design bug of having the CVS .rcs files on a different disk to that of the CVS daemon itself - adding untold latency to each NFS file operation.
