OpenOffice and go-oo

[Caolán McNamara]

On Mon, 2008-10-13 at 09:57 +0100, Aidan Delaney wrote:
> Dear all,
> 	Has there been any discussion of why Fedora ships a relatively stock
> (stock + 98 patches) OO.o rather than shipping go-oo?  

I judge that this route provides the stablest and best supported product
for fedora users. We have a very reliable OOo in fedora. Well, we have
an OOo in fedora with a very low incidence of open reported bugs, which
isn't necessarily the same thing :-). My logic follows a route something
like keeping the product we have closest to the product that most
OOo-developers have, so that the full upstream qa and developer
resources are applicable to it. With a fairly aggressive push of any
fedora patches back upstream asap (where
http://qa.openoffice.org/issues/show_bug.cgi?id=90439 tracks the
additional patches we carry at any given time and their upstreamed
issues). Currently 47 patches for 3.0, against 98 for 2.4.1. Ideally it
would be 0.

> the opengl slide transitions

They're still in a bit of a confused state, but I hope to see these in
Fedora for F-11. I felt it was a bit much to take on for 3.0 with the
simultaneous complexity of a three-layer OOo and more reliance on OOo
extensions. 

> Particularly when go-oo appears to contain a superset of the Fedora
>  OO.o patches.

I've no beef with ooo-build at all, and its a fine resource, and we work
with them quite a bit. We carry their gstreamer stuff for example, and
they carried (before it was merged into vanilla) our fontconfig glyph
replacement stuff, etc. Its also possible to e.g. use ooo-build, create
a fedora section in it, and in that section just reference the specific
patches that would be applied in addition to vanilla. Various
distributions built out of the ooo-build tree generally pick what
patches in ooo-build to apply, so go-ooo.org variants can and generally
do vary from eachother as to what is in them. You could think of
ooo-build as a pool of available additional nifty patches and an
infrastructure of picking which ones to apply.

One practical day-to-day reason for not doing that for example is that
ooo-build is a set of patches, so for e.g. a security errata on OOo
using ooo-build is that you can end up with patches for patches for
patches, and then my brain fries and I get physically pained at the feel
of limited developer time draining away into packaging administrivia.

C.