incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <>
Subject Re: Hauling in third-party code (was: Category B licenses)
Date Wed, 29 Jun 2011 19:46:06 GMT
On Wed, Jun 29, 2011 at 1:34 PM, Greg Stein <> wrote:
> On Jun 29, 2011 7:54 AM, "Jens-Heiner Rechtien" <> wrote:
>> On 06/29/2011 01:19 AM, Greg Stein wrote:
>>> This process sounds exactly like what the "buildout" tool[1] is
>>> designed to handle. It seems like a good opportunity to move from
>>> OOo's homegrown system to something that is supported, documented, and
>>> maintained by others.
>> The system we currently have is effective - and it works now. I agree that
> there are better and more standard ways to do this but I guess it's not our
> first priority, maybe not even our second.

volunteers scratch their own itches ;-)

> It's a whole lot of stuff and it has to work on Windows as well.

Would python be good enough for this?

>> Introducing something as buildtools will be the perfect time sink for
> someone overhauling the build process. And I would hate it if the change
> would stop somewhere in between - I've seen many tries to standardize stuff
> in OOo which ended prematurely leaving us with *two* ways to do things.

Any replacement would need to be developed in parallel

> It's very easy to underestimate the effort given the sheer size of OOo.

A PMC needs to be able to provide oversight and verify releases. The
size of OOo is going to make this difficult.

Is the current plan to integrate the release of the homegrown build
tool with the rest of OOo?

>> Of course if someone is willing to do this, that would be great. But it
> takes a lot of commitment to see the changes through.
> Right. Agreed!


> Just throwing it out there. I think it could be a great way to reduce
> maintenance in the long run, but recognize there is a big hurdle to cross
> first.


I'm concerned about being able to verify official OOo releases. If
switching to buildout (say) made automated auditing and oversight
easier then it may well be worth the effort.

>>> Reviewing those patches would also be good. Try and get more of them
>>> upstream. For example, I saw some patches to Neon in there which
>>> should get pushed upstream, and also move to the latest version of
>>> Neon.
>> Always a good idea to do this, but if I remember right especially neon was
> occasionally unresponsive regarding some of our patches. But I guess every
> downstream project complains about upstream being unresponsive :-). But I
> know that we've updated neon support regularly over the last years.
> Yeah. We'd always like upstream to love us :-)



View raw message