OpenOffice and go-oo

Caolán McNamara caolanm at
Mon Oct 13 09:55:07 UTC 2008

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 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

> 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 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.


More information about the fedora-devel-list mailing list