Difference between revisions of "Infrastructure Problems"
(→Wiki) |
(→LXR / Bonsai / Tinderbox) |
||
| Line 65: | Line 65: | ||
=== LXR / Bonsai / Tinderbox === | === LXR / Bonsai / Tinderbox === | ||
| + | |||
| + | With 8 million lines of code no-one outside Sun is familiar with, is is essential to have some hard-code code search, change tracking, indexing functionality. Unfortunately SourceCast does not provide this, that makes it way more difficult to collaborate on developing the code. | ||
| + | |||
| + | A central well-maintained Tinderbox server, should be a pre-requisite for any large project with as many complex build issues as OO.o. One is provided at http://go-oo.org/tinderbox/ however. | ||
=== RSS aggregator / 'planet' === | === RSS aggregator / 'planet' === | ||
Revision as of 10:21, 15 November 2005
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 (broadly) a failed 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. Of course, this is not un-fixable, and the situation improves daily but this is where we are now.
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.
Access control - the CVS repository was by default is constructed in such a way as to deny even those granted access commit writes to large chunks of it. This was coupled to the formal role request/granting process.
Projects & roles
There is an extremely formal project / role structure built on SourceCast's features in this area. Unfortunately extremely formalised structures, with roles 'project leads' etc. is inimical to the rapid transition of this large code base towards more external contribution, influence, interest etc.
Worse - in order to contribute it is necessary to be 'granted' a role; which occurs via a length E-mail round-trip to the project-lead, further hindering development. ( This is broadly fixed these days by creating more un-constrained accounts in the 1st instance ).
IssueZilla
Community Management
Collab.net provides the services of Louis Suarez-Potts as a 'community manager'. Louis is an excellent, engaging & pleasant person - this is not a personal critique. However - it has to be pointed out that Louis is not a developer.
This has several unfortunate consequences - when speaking at conferences worldwide, it is difficult to generate the vital 1-to-1 personal bonds that are the real substance of community, to empathise & assist with development issues, to encourage the growth of a true developer community. It is also possible that this leads to exacerbating other structural, and proceedural problems, and over-dependence on formal process rather than developer-to-developer relational interaction, an unhealthily centralized set of relations, and a lack of meritocratic accountability; where merit is based on hard contribution: code, translation, etc.
Missing services
Wiki
It is (apparently) possible for 'anyone' to edit the project pages in source-cast; however one has to engage with this formal role based process and argue with whomever arrived there first and got a 'project lead - obstruction project' role; get cvs commit access etc.
A wiki provides way more freedom for people to get involved with editing content & thus substantially lowering the barrier to improving documentation, etc. Indeed - a wiki (it may be argued) is a great re-application of traditional Free-software liberal attitudes to code contribution into the field of web/docs. Unfortunately those traditional liberal principles tend not to be applied in OO.o
LXR / Bonsai / Tinderbox
With 8 million lines of code no-one outside Sun is familiar with, is is essential to have some hard-code code search, change tracking, indexing functionality. Unfortunately SourceCast does not provide this, that makes it way more difficult to collaborate on developing the code.
A central well-maintained Tinderbox server, should be a pre-requisite for any large project with as many complex build issues as OO.o. One is provided at http://go-oo.org/tinderbox/ however.
