Difference between revisions of "Ooo-build"

Revision as of 21:47, 14 November 2005

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.

symbol font

ooo-build contains a substantially improved OpenSymbol font: opens___.ttf improved mostly but cut/pasting existing glyphs to new positions to match the mapping table in vcl. This results in a massively improved PPT/Word bullet experience with little effort. It is not acceptable up-stream for reasons unexplained.

font substitution

Many vendors ship AGFA's propriatory metric-compatible fonts with OO.o - it is thus necessary to run several seds on the VCL.xcu [ further bloating this already gigantic messy beast ]. We also remove some of the more foolish & enthusiastic font-usage of eg. the metrically-extremely-strange bitstream font eg. bin/font-munge.pl

   s/(Bitstream Vera Sans;.*)Albany;/Albany;$1/;
   # add AMT fonts
   s/Albany;/Albany AMT;Albany;/g;
   s/albany;/albanyamt;albany;/g;

parallel build support

There are a chunk of ice-cream / massively parallel fixes in ooo-build, it's not clear who owns reviewing / accepting these up-stream.

no 'UI' team

The up-stream UI team have come up with master-pieces of UI design such as the Yes/No dialog on

"Would you like to not continue saving in the original OpenOffice.org 2.0 format or perhaps switch to another format"

that takes 10 seconds to parse each time ( presumably since it's a recent feature - with a specification too ).

The rest of us mere-mortals know that the OO.o is shockingly broken - and hence are eager to fix it without being blocked & frustrated for weeks by those responsible for the current mess.

A number of the changes / patches in apply/ are blocked on 'user experience' feedback.

different defaults

It is self evident to ooo-build users that a slew of dialogs on 1st run is a painful mess; eg. if there are settings to migrate, don't shout about it - do it silently. Furthermore - the registration dialog looks tacky, we disable both. We also alter a number of other defaults. cf. the last point - I'm optimistic that these will ~never get up-stream agreement.

bleeding-edgeness

There is a 'cool factor' to building the very latest things yourself; and helping solve problems with them. It's nice to be able to see your changes have an effect & help others rapidly, eg. a fix being immediately useful to other people. Of course - you can have too much of a good thing here but ...

Philosophical differences

compatibility

Up-stream believe that the most important data set to be compatible with is existing StarOffice / OO.o users. ooo-build users believe that nearly all the world's data is stored in Microsoft Office format - hence we sacrifice legacy support for better interop. This is of course a continuum, up-stream are at the luney extreme of pushing back-compatibility regardless of it's impact on interoperability, even in cases deliberately excluding useful interoperability improvements on that basis. ooo-build appreciates backwards comaptibility, but is in favour of viewing core differences that are non-interoperable as bugs not features.

process complexity

ooo-build users believe in programmer lead development, with strong peer review and user QA. up-stream believe in process based development, with teams, consensus building, specification writing, test-instead-of-detailed-code-review, and all these 'Professional' pasttimes. ooo-build users believe the OO.o we have today is broadly a product of these processes. Up-stream users believe the previous sentance to be a complement.

cross-platform

ooo-build enables patch sub-setting, thus we include patches for features (eg. Mono integration) that are most likely not well separated, and will break the Win32 build. Of course, for ooo-build these are not enabled on Win32 thus causing no problem. This is an impediment to getting work up-stream. Hopefully the 'experimental' process may help encourage good behavior here.

FIXME

Lots more to be said here ...

Conclusion

If you read all that don't get depressed - these issues can all be fixed - many of them almost painlessly. We hope to shrink this page quickly.