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.
- 1 About ooo-build
- 2 Building
- 3 Fixing
- 4 Releasing
- 5 Branching
- 6 Remaining unsolved issue summary
- 6.1 source handling
- 6.2 cvs slowness
- 6.3 compile fragility
- 6.4 interlocking changes
- 6.5 non-responsiveness / lack of leadership
- 6.6 symbol font
- 6.7 font substitution
- 6.8 parallel build support
- 6.9 no 'UI' team
- 6.10 different defaults
- 6.11 bleeding-edgeness
- 6.12 Philosophical differences
- 6.13 FIXME
- 7 Conclusion
- ooo-build/bin - A description of the tools in bin/
Sample simple fixes
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.
faster 1st time (packagers/developers) build
Dependency generation takes a huge chunk of CPU time - simply detecting a pristine build & exporting 'nodep=1' trivially saves a chunk of time - should get that up-stream.
easier developer experience
Trivial, built-in, automated use of the system malloc allocator checker (via linkoo & source ooenv), also - by default disabling the (incredibly annoying) 'recover from crash' dialog stuff via a similar trivial environment variable patch: i#54275.
When there's a particularly good reason for a release, such as a distro needs a stable base or we want to do something potentially disruptive, one of the core ooo-build hackers will follow something like this process:
- cvs update - get the latest everything
- Read back through the ChangeLog and update the NEWS file for the release, summarizing and attributing the changes.
- edit configure.in, bump the version in the AC_INIT line, incrementing the minor version eg. AC_INIT(ooo-build, X.Y.Z)
- Add a line to any handy ChangeLogs, so we can easily see where this happened in the flow:
2019-13-33 Ned Squeers <firstname.lastname@example.org> * Version X.Y.Z
- ./autogen.sh - this re-builds configure with the version in place; a distro must be specified eg. ./autogen.sh --with-distro=SUSE
- make dist - this builds the archive containing everything.
- cvs commit - so what's there is what's there. If there was a collision you get to loop to the first stage here, but don't re-increment the number.
- cvs -z3 tag OOO_BUILD_X_Y_Z - this leaves a static tag so we can reproduce the build at any time and easily diff between releases.
- md5sum ooo-build-X.Y.Z.tar.gz > ooo-build-X.Y.Z.tar.gz.md5 - so that users can do at least the basic consistency check
- scp ooo-build-X.Y.Z.tar.gz* email@example.com:/var/www/packages/<MWS_DIR>/ - uploads the tarball and the .md5 file for the right Master Work Space, eg. SRC680
- It's then customary to announce the release, see the template in doc/announce.txt - update all the ***s to the right versions, insert the contents of NEWS, fire and forget.
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.
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 of course necessary to have source archives that include the CVS directories & information, (or perhaps split that out into another package - but yet make it available) - such that developers can easily 'cvs diff -u' to extract their changes, and of course tinderbox slaves can base off these archives.
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.
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 CVS server.
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.
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.
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.
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.
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.
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.
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 ...
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.
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 sentence is a compliment.
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.
Lots more to be said here ...
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.