incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Fri, 01 Jun 2012 08:16:39 GMT
On 5/31/12 6:26 PM, Pedro Giffuni wrote:
> 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
> 

I hoped that was clear, our source release files don't contain any
tar-balls from ext_sources

> 
> Build on it's own? Or are developers/builders expected to download
> more tarballs from SVN.

yes, you unpack the source, solve some basic build env requirements
according the building guide, run configure and build. The tar-balls get
downloaded during the bootstrap step automatically.

After checking it again, the only drawback currently is that all
tar-balls are downloaded even if they are not used. That is true for all
categories.

But this is something that we can improve for the 3.5 (already started).
We should only download the tar-balls that we need by configure ...

Why not 3.4.1? Because it is a maintenance release only and we want to
be careful. For 3.4.1 we change the url to download from our 3.4 revision.

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

exactly the tar-balls are downloaded via the svn url (see the ooo.lst
file) on demand if they are not already present. When you checkout trunk
you get them and the download is not necessary. Well that is what I
meant with convenience.

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

that is true, but they are not used without further action or to
explicitly enable them.

I never said that it can't be improved and having the tar-balls in trunk
is of course not the best solution. As we have seen right now with the
latest updates that will or can break our source release when someone
use the correct configure switches.

And of course we agreed to move them and adapt the download scripts.

The whole mechanism is a little bit comparable from my pint view with
maven and how maven solve external dependencies.

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

well that is a very bad example and probably wrong. We all know or
expect that not many people will build AOO from the source release.
People who are interested will more likely check it out from svn as you
and I did it as well.


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

well that is exactly the question. I don't know for sure if it is a real
problem to have them in svn.

svn or any other server would be equal as long as we don't
change/improve the download part.

So the real problem seems to be a different one.

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

sure and I never said something different and we started working on it.

My point was more that I didn't put this in relation with the
graduation. And I never argued in a way to increase any pressure to
influence a decision or vote. It's fine to raise concerns and even
better to start work on solving the underlying issues.

Juergen


Mime
View raw message