Difference between revisions of "Infrastructure Problems"
(remove offensive bits / re-work / rename page.) |
m (Collab.net moved to Infrastructure Problems) |
(No difference)
| |
Revision as of 11:53, 17 November 2005
Contents
Infrastructure problems
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. Similarly the CVS structure itself (split into separate top-level modules per-project) is confusing (not matching the source directory layout), also making it not possible to have a 'familiar' structure, configure / autogen.sh / README / BUILDING etc. in the top-level directory. [ at least without breaking other CVS operations ]
Searching
There is no ability to search openoffice.org without logging in, there's no good reason for that. More seriously googling doesn't show any results from within the mailing lists! Making them nigh on useless as a resource. Whatever needs to be done to get them googlable should be a priority.
Hint: as a workaround, for fast and easy mailing list searches and a threaded archive go to mail-archive.com, e.g. http://www.mail-archive.com/dev@openoffice.org/, combined with Google this leads to something like site:mail-archive.com/dev@openoffice.org YourSearchTerm, which works in many cases. Of course there are also others like Gmane and such.
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
This is rather old & nasty compared with the excellent modern Bugzilla releases, that shows in lots of places - file typing, uploads, comment management, well - tens of usability & cleanup features missing.
Mailing lists
It is critical in any new Free software project to attract developers. One way to drive away newbies is to have an unstated rule that anyone who wants to get a reply from a mailing list post needs to add "please CC me I'm not subscribed - and retain this message so the rest of the thread reaches me" in a prominent place in their E-mail. Thus (I imagine) people regularly ask a question on a list, and recieve no reply, even if one is written.
Futhermore address munging is a hugely bad idea for busy mailing lists - it is not possible to read all (busy) mailing lists on topics that people are interested in in linear time; hence keeping a thread CC'd to one is important, it allows a quick response - while keeping the mailing list informed. This is not possible with collab-net's Reply-To: mangling - hence discouraging busy people from using or CC'ing the mailing lists.
Also Reply-To: mangling is just a bad idea, cf. Linux Kernel, GNOME et. al's non-invasive, non-munging policies that encourage contributors & build collaboration.
It may be that one reason behind this mangling is to discourage people from replying off-list to people. This seems incredibly small minded - communities are built of strong personal bonds between individuals, not primarily some hub-and-spoke relationship with 'a mailing list'; however this is a minor issue; people have a vested interest in having their answers recorded, archived & publicly searchable, they then have to answer the question fewer times.
It is believed that underneath SourceCast uses [1] underneath.
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.
