incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer ...@a-w-f.de>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Thu, 31 May 2012 11:54:18 GMT
Hi Pedro,

On 31.05.2012 03:45, Pedro Giffuni wrote:
>
>
> --- Mer 30/5/12, Rob Weir<robweir@apache.org>  ha scritto:
>
>>>
>>> So *NOW* you are admitting that those tarballs are
>> part
>>> of the Release??
>>>
>>
>> Not at all.  But they are referenced from build
>> files.  I hope this distinction is clear.
>
> No. If they are just referenced then we don't depend
> on having them there: we just have to replace the
> reference. A nice text file mentioning where to find
> them (ooo-exttas @ Apache Extras) *is* a reference.
>
>
>> Again, go back to the licensing page and the principles
>> stated there. This is not a crusade to eradicate
>> category-b code from the face of the earth.
>
> I didn'r say I am eradicating anything (yet), they just can't
> be in SVN.

Good.  May plan is to use this opportunity to make the fetch_tarballs.sh 
script handle more than one download site and be more fault tolerant. 
Until then it is important that the tar-balls stay where they are, 
regardless of their licenses.

>
>    This is about making it clear to downstream
>> consumers what
>> the dependencies are, what obligations those dependencies
>> bring, and
>> to require an explicit, informed decision for the downstream
>> developer
>> to enable the use of category-b binaries.    We
>> are doing all of that.
>>
>>> We don't have permission from legal@ to ship
>> Category-B
>>> sources .. that must be fixed .. with axe.

I don't agree for several reasons which all have been discussed to some 
length.

>>>
>>
>> Put the axe away, Pedro.   As you know,
>> category-b code is not
>> included in the release.  We already went through the
>> audit on that.
>>
>
> There was no audit. Mr RAT never examined those and we
> discussed this was a temporary situation.
>
>> In case it is not clear, I'll veto any attempt by you to
>> break the 3.4 source distributions.

+1

But I am afraid that this has already happened (see below.)

>>
>
> You mean source distribution (tarballs) don't build on
> their own and depend on what we carry in SVN? Sounds
> like something is wrong.

It will still build but without the tar-balls there will be missing 
features.  And I think that missing features are much harder to explain 
to end users than a clean license status.

>
> Well ... those files are not required by default for
> the build, they are only optionally used and we did it
> on purpose so as long as we make a small adjustment in
> the buildbots I don't see what you can veto about it.
>
> And while you are so brave about vetoing hypothetical
> issues ... I already axed a couple of tarballs from the
> old Apache commons and Lucene. Have fun putting them
> back :-P.

Good that you mention this, but not so good that you did it.  Someone 
(you, me or someone else) will have to recover the old versions of these 
libraries.

Without the previous versions in trunk the ooo.lst file in the (source) 
release points to files that are not there anymore.  configure should be 
able to handle this but will disable some features.


Pedro, I understand that you don't like the category-B libraries.  I 
agree that we should try to get rid of them.  But I think that we should 
do this more carefully.  Breaking existing releases is a bad thing. 
Losing features in coming releases is also a bad thing.


Regards,
Andre

Mime
View raw message