Hi Pedro,
On 31.05.2012 03:45, Pedro Giffuni wrote:
--- Mer 30/5/12, Rob Weir<[email protected]> 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
