incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [PROPOSAL] Starting the graduation process
Date Wed, 30 May 2012 07:26:13 GMT

On May 29, 2012, at 11:41 PM, J├╝rgen Schmidt wrote:

> Hi,
> 
> sorry for top posting but I would like to suggest that we come back to Rob's initial
question.
> 
> Simplified:
> Should we start graduation now?

Yes, as long as we understand that the following is an evolving issue regardless of whether
we are a TLP or part of the Incubator. The IPMC will certainly tell us if it is a blocker
to graduation. I don't think it is, but someone else will differ. The IPMC is as big as this
PPMC, there is lots of room for difference.

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

It might be worth bringing this question to general@i.a.o and pre-flight opinions. It helped
with the release, it can't hurt graduation.

Regards,
Dave

> 
> 
> Juergen
> 
> 
> 
> On 5/30/12 4:21 AM, Pedro Giffuni wrote:
>> Hi;
>> 
>> --- Mar 29/5/12, sebb<sebbaz@gmail.com>  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] http://www.apache.org/legal/resolved.html#category-b
>>> 
>> While [1] is the official document, I find the original
>> draft policy explains things much better:
>> 
>> http://www.apache.org/legal/3party.html
>> 
>> cheers,
>> 
>> Pedro.
> 


Mime
View raw message