incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: [PROPOSAL] Starting the graduation process
Date Wed, 30 May 2012 06:41:36 GMT

sorry for top posting but I would like to suggest that we come back to 
Rob's initial question.

Should we start graduation now?

Pedro's concerns are valid. On the other hand the question is what 
really changed when we move the source tarballs to a different place?

I think Rob tried to explain that there is no real difference. And we 
don't include any category-b source in our source release package.

Well I would support both solutions for now but I am in favor to have a 
long term solution to replace category-b libraries where possible as 
Pedro has already pointed out for some libraries.

But we should keep in mind that this changes are not trivial and the 
work have to be done by somebody. We analyzed for example the address 
book replacement and postponed it because it is a huge task and 
potentially we can replace it later by switching to native platform 
support on the different systems...

Some patches for libraries can't be up-streamed because the maintainer 
is not interested in patches that introduce the stlport for example. The 
problems are sometimes very simply. That means we have first to 
eliminate the stlport dependencies and use the compiler stl and can drop 
further dependencies in a second step and can use binary packages 
directly. I could list more examples and I don't think that we ignore 
this items. We have thought about it very careful and have done what was 
possible in the release time frame.


On 5/30/12 4:21 AM, Pedro Giffuni wrote:
> Hi;
> --- Mar 29/5/12, sebb<>  ha scritto:
> ...
>>> This is admittedly a stop gap solution to comply
>>> better with the Apache policies, the real fix would
>>> be to work collectively on replacing the code that
>>> can be replaced:
>> Alternatively, it is possible to include cat B [1]
>> dependencies in binary form.
> We do this for FreeBSD and it works great.
>> Is there any need to include the source?
> No. The real reason why OOo historically has carried
> the sources for everything is/was that previously the
> GPL forced developers to make the sources available.
> The issue is the multiplatform support. For builders
> on platforms like Windows it's not really fun to go
> looking for the different dependencies. This said,
> for Java stuff it is perfectly OK to include only
> binaries (except for our old saxon-B, which is
> deprecated upstream so we have to carry the sources
> somewhere)
>> [1]
> While [1] is the official document, I find the original
> draft policy explains things much better:
> cheers,
> Pedro.

View raw message