Ooo-build

This collection of patches, artwork and build infrastructure exists solely as a reflection of the many problems encouraging reasonably responsive change up-stream. The process of change is painful for any organisation, the larger the more painful. However - the size of the problem is no excuse to not try; hence the evenutal aim is to remove the need for ooo-build by incrementally fixing the various problems.

About ooo-build

ooo-build arose from acute frustration with the bad-old days of OO.o process before the Child Workspace concept was introduced, it is also fueled by incredibly non-performant CVS server provided by collab.net.

remaining unsolved issue summary

A helpful summary of these is provided here in no particular order along with suggestions for improvement. Many of these are mercifully easy to fix, and should be fixed soon.

source handling

src packaging

We have habitually split the source into several pieces to aid downloading. The process of achieving this is codified in a simple shell-script [here]. It is probable that up-stream release source archives for each milestone in a timely fashion - but having used them it's not clear to me where they arrive. (FIX-ME).

src download

ooo-build has a post-configure 'download' mechanism, whereby the relevant source archives will be automatically downloaded to your system having configured it, in response to your various options.

cvs slowness

It can take multiple hours to tag (once) the full up-stream CVS; this is not conducive to some of the more funky 'nested workspace' ideas based on the CWS tooling becoming a reality. Adding large modules to a cws currently takes way too long. Interestingly, it's can be quicker to do a $ cvs diff, create a new cws and apply the patch than re-sync a cws. It also helps to have the diff in hand in case the cws tools fail mid-flow, since that has been known to loose data. A 'diff -u' by contrast, or an anonymous diff from cvs - combined with ooo-build's intelligent patch application process often results in an extremely fast development cycle unincumbered by low performance collab.net infrastructure.

compile fragility

To use up-stream OO.o it is not possible to use HEAD, due to multiple concurrent (slow) incomplete merges constantly in progress, instead one must use a milestone release. Unfortunately milestone releases build on a small number of tested setups - but these typically do not include out-of-the-box, stock Linux distributions such as OpenSUSE, Fedora, Debian etc. Thus from day-1 it is necessary to patch a milestone to get it to build at all. Issues such as different gcc versions, different platform libraries etc. tend to cause this. However - there is no central place where such patches can be collected to avoid constant duplication of effort, apart from ooo-build.

It is hoped a tinderbox server with many disparate slaves building the CWS in the 'Ready for QA' state might help fix this problem in future.

interlocking changes

While a cws is waiting to be integrated / going through QA - it is entirely possible that another feature requires the functionality it provides; furthermore there is no easy way to include multiple features that we judge to be ready, yet would not pass up-stream QA (on multiple platforms etc.) into our builds. Thus ooo-build becomes a place to test multiple new features concurrently. It is hoped that the new experimental CWS regimen may help fix this problem & accelerate up-streaming of patches.

non-responsiveness / lack of leadership

Many ooo-build patches are ready for up-streaming but there is no / little response from up-stream. Worse there is the perception that taking leadership and actually doing something about merging fixes would be firmly opposed. Finally - even when maintainers are active, responsive & friendly - there is no agreed mechanism for blanket approving fixes - or sub-types of trivial fixes, which thus tend to fester in IssueZilla.

At the time of writing ooo-build's patches are available here: http://go-oo.org/ooo-build/patches/src680/apply.

FIXME - add some humerous details here / bug links etc.

Win32 / configure auto-detection

We have a nice perl script 'oowintool' that does a rather better job of auto-detecting various system tools than up-stream, we should integrate it there - it makes the common case much easier. cf. the last point though.

branding / artwork / splash bits

Many of the ooo-build patches are simply branding changes for other distros. Getting that up-stream plus a combination of selectable 'experimental' features would prolly remove the usefulness of ooo-build substantially for these people. Altenatively perhaps good docs and a --with-splash=/tmp/foo.png --with-logo=/tmp/baa.bmp might work nicely.