About ooo-build

0. Contents

• 1. Why ooo-build
• 2. Getting involved
• 3. Downsides
• 4. Areas for improvement

1. Why ooo-build

There are a number of reasons for the existence of ooo-build:

• 1. CVS doesn't scale
• 2. OO.o process is too slow
• 3. build / package infrastructure
• 4. lack of interest in up-streaming

1.1 CVS doesn't scale

A simple cvs tag of the whole of the OO.o tree can take several hours to complete; thus if you want to have a very extensive patch set against OO.o you cannot work at a sensible speed. All cvs operations, branching, merging, re-synching even simple updating, take a very considerable time. Working from a separate base tar.gz and a flexible patching system allows the maintenance of a branch very much more easily.

1.2 OO.o process is too slow

Why do we have to have a branch, and a large patch set at all ? why can't we just work directly from OO.o CVS.

There are several answers here: primarily that CVS commits are extremely restricted, the approval process from IssueZilla submit to eventual CWS commit, to CWS merge takes a matter of weeks; this is no way to create excitement, and provide fast problem fixes. Furthermore, there are contraints to merging to a stable branch that disallow many changes. Large changes cannot happen eg. (a base vtable change, new icons) since Sun have to ship binary bug fix updates - which are required to be reasonably small (ie. not all of OO.o again).

Furthermore, Sun will only accept patches after receipt of a posted / FAXed, signed JCA. While we feel the JCA is a vital to OO.o and mandate it's use for ooo-build commits, we are happy to prune this postal / processing / CVS account bug ticket creation / CVS account bug ticket assignment to collab.net / CVS account creation / commit latency. With assurance of an in-flight JCA - we can create a CVS account quickly and get you working with a handful of hours.

Sun has a need for a highly stable / buildable branch from which they can make releases. There are two approaches to get a stable/buildable branch:

• A. Mandate stringent testing, code review, debug builds, and highly restricted commit access.
• B. Encourage a culture of carefulness, and highly unresticted commit access.

Of course - hopefully at some time in the future problem 1.1 may get fixed - at which point keeping a branch in OO.o cvs that allowed sensible communal development, while allowing merge-backs to stable would be feasible.

1.3 build / package infrastructure

The core OO.o build process is not easy to use, and the packaging process on Unix is anachronistic, and inflicts incredible pain on sysadmins and users. Thus, this has to be worked around externally to OO.o. This is a substantial amount of work - unfortunately, it seems the re-creation of a Unix build is also a pending internal task - hopefully this will not result in an even bigger mess of alternative packaging schemes.

1.4 flexible staging ground for patches in progress

We have introduced a way to select a subset of patches to apply to a particular build. For example, Ximian uses a set of patches to use CUPS as the printing system, which Debian, as a more general distribution cannot do, but both packages use the fontconfig support.

It also gives the patches a chance to be tested by a wider user community while they await integration into the main version.

1.5 lack of interest in up-streaming

There have been for many years, very many patches against OO.o to do all manner of useful things. Many of these have been submitted under the JCA. The pace of adoption of these changes is really depressingly slow; and the level of engagement with external contributors poor. In some cases whole chunks of functionality have been re-written internally without reference to, acknowledgement of, or discussion with the original author - this phenomenon continues apace.

2. Getting involved

2.1 Communication

Without communication it's impossible to co-ordinate what is being done. It's also impossible to have any confidence that your patch will be useful / nicely designed. To try and overcome this, and to encourage each other - we hang out on channel #OpenOffice.org on irc.freenode.net, you'll soon get to know the team. See also here to see who is whom.

2.2 Your first patch

The process for submitting your first OO.o build patch is extremely simple:

• Sign and post the JCA; see here
• Create a perl crypted password: perl -e "print ':'.crypt('mypassword', 'zt').':';" 'zt' should be 2 random chars, and 'mypassword' should be a strong password.
• E-mail this crypted password with your full name, and contact E-mail address to michael@ximian.com and/or halls@debian.org.
• If you're in European time poke michael / haggai on IRC.
• Re-checkout openoffice from the master CVS server: export CVSROOT=':pserver:jsmith@cvs.gnome.org:/cvs/gnome'
  cvs login
  cvs -z3 checkout openoffice
  NB. your account name will usually by InitialLastName as above.

• Create your patch (diff -u etc.)
• Submit the patch to IssueZilla - this is about the most painful bit: re-login (again), 'File an Issue', commit the issue, attach the patch - remember the IZ number.
• Commit your patch to the build set you're interested in, and add the patch name to the 'apply' file - add a short comment describing what the patch does, and append the IZ bug-number.

3. Downsides

Of course this has a number of obvious down-sides for you as a contributor:

• Working outside CVS makes up-streaming harder, and commits somewhat more painful.
• You get no immeditate 'official' recognition; no-matter how large your contribution to OO.o you don't exist in the eyes of the artificial OO.o community as ooo-build is not an 'official' project; however - we value you more.

4. Areas for improvement

Obviously the existing situation is highly sub-optimal, here are some possible improvements beyond our control that could be made:

• 1. accelerating CVS performance - this is a hard task, possible subversion may solve this in due course. A more feasible alternative would to devote resources to committing to merging CWS' targetting stable to a parallel playground branch in OO.o CVS as well [ thus avoiding painful community merging ].
• 2. accelerating OO.o CVS account creation, binning ACLs and hugely increasing access (& trust); thus we can get more people involved more quickly without demoralisation.
• 3. aggressive interest in working with external people, and merging their patches; this involves at a minumum:
  • Rapid response to design queries.
  • Research and response to other OO.o development streams and their patch sets; discussion of requirements for merging.
  • Clear, interactive, casual access to relevant developers to discuss design before larger changes are attempted.
• 4. recognising the needs of Unix packagers to have substantial wrappers / work around OO.o, and allowing them to integrate all of it, leaving no need for separate branches.