incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <>
Subject Re: OOO and LibreOffice.
Date Thu, 07 Jul 2011 12:10:11 GMT
On 07.07.2011 13:09, Ross Gardler wrote:

> On 6 July 2011 23:51, Andrew Rist <> wrote:
>> To date the LibreOffice crew has taken the effort to merge in changes from
>> the OOo code line, for each release.
>> The most obvious and best way to collaborate in the future is to write good
>> code, and make it worth their while to integrate it into LO.
>> The more compelling the development effort at Apache, the more likely it is
>> reused by LO.
>> This also leads to the situation where they have an interest in pushing
>> changes into the AOOo code line, to simplify their future merges.
> I agree 100% with this.
> My question, as someone who does not know the OOo code, is are there
> any obvious places in the code where this is likely to happen?
> A strong Apache project has the broadest possible community of users.
> Some of these users become contributors and some of those become
> committers.
> I wonder if there are any units of code that can be separately
> packaged in order to allow them to be included in downstream projects
> without "merging cnhanges" into a separate code tree?
> I'm a Java weenie, so I think in terms of JARs that can be reused
> easily. Is there any scope in the OOo project for similar library
> reuse? If so where is the low hanging fruit?

Whether you need to merge changes does not depend on the code itself, it
depends on whether you have any changes done and if you want to push
them upstream. These changes can also appear in code that otherwise
could be reused easily.

IMHO it's not a matter what code can be shared easily as a separate
package, but where merging code changes is harder. Sometimes there's a
relation between these two, but not always. The more active development
in a particular code part happens on both sides, regardless how the code
is packaged at the end, the harder it will get to merge the changes.

Nevertheless it would be an interesting approach to package some stuff
separately and give it a life independent from the OOo application code
base. Ideal candidates would be UNO and its runtime libraries (URE), the
SDK and the build system. That's the reason why I recommended these
areas as a field for collaboration, with the goal to establish trust and
relationships between the developers that we can build on.


View raw message