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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list