incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Thu, 31 May 2012 16:26:15 GMT
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:

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


View raw message