Hi Jürgen; Let me clarify some issues too ...
On 05/31/12 10:39, Jürgen Schmidt wrote:
... let me explain some details here because I think they can help to understand. 1. we have dependencies to several external libraries including category-b for some features 2. we have checked in all this source tar-balls in ext_sources for convenience and to ensure that they are always available. Another option would have been to host them somewhere else on extras or any other reliable server. We use the easier way for convenience reasons I think. 3. our source release don't contain any category-b source tar-balls
First of all we should clarify what a source release is in this context. Does our source release contain Category-A tarballs? In other words, does this file: http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2 Build on it's own? Or are developers/builders expected to download more tarballs from SVN.
4. from a source release perspective we don't make use of any category-b stuff per default. A user have to explicitly trigger the use of category-b stuff and related features. The tar-balls are downloaded on demand, some kind of dependency mechanism if you want.
So if we remove the Category-B tarballs from SVN the default build doesn't break, this is important. Now.. if the tarballs are downloaded on demand, are you meaning those are downloaded from SVN? (It's an honest question: I normally checkout all the tree from SVN, including the Category-B, tarballs so I haven't experienced the on-demand part of it)
5. the download on demand is the same and I don't really see a difference between downloading the tar-balls from svn or any other place.
OK. Do note that doing a SVN checkout, as suggested in CWiki, there's no easy way to exclude the category-B tarballs: svn co https://svn.apache.org/repos/asf/incubator/ooo/trunk ooo
6. we agreed to upstream changes to external libs where possible and necessary. And we agreed to improve the workflow to use the tar-balls from their original source where possible over time and where we can rely on the overall availability (e.g. dependencies to Apache libs, etc.)
Yes. Most of them are just uninteresting upstream.
It seems to be really an item for legal to decide if hosting the category-b tar-balls in svn is not allowed for convenience at all. Furthermore we agreed to accept and of course support the move to another server but it is important that we don't break our 3.4 release.
As you noted before, removing Category-B tarballs shouldn't break the default build. But I will go further ahead with mentioning that the 3.4 Release is theoretically broken already with the Lucene and Apache Commons updates (the development branch is for development, right?), and since no one complained people must be getting the files from somewhere else.
We also agreed to clean up as much as possible of the dependencies to category-b stuff over time. But that takes time and is a lot of work.
I admit this is very clear. I don't expect such development to be a requirement for graduation but the transitory situation of a source release that depends on carrying category-B tarballs in SVN now is not really acceptable.
We are also open for any other action that we have to take to be conform to existing policies. I think we have shown in the past that we take everything serious and address issues in time where possible.
I hope you agree that solving the issue is possible. Pedro.
