incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Fri, 01 Jun 2012 16:37:39 GMT
Hi Jürgen;

On 06/01/12 03:16, Jürgen Schmidt wrote:
> On 5/31/12 6:26 PM, Pedro Giffuni wrote:
>> ...
>> 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
OK. So what we are releasing is only the part of the SVN tree labelled 
"main",
(not sure if ext_libraries is included, it should be). I would think a 
source
release should be able to build without having to look for extra 
libraries in
our SVN. Call me old fashioned but I am thinking of people trying to
distribute the sources in a CD-ROM.


>> 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.
I think all releases must respect Apache policies ASAP.

>
>>> 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.
I think the problem is your definition of source release. The source release
in the source tarballs should be 1:1 equivalent to the source release in 
SVN.
If you think release (in the tarball) is only what you have under "main" 
then
we do have trouble moving dependencies in the tree. but if you include the
tarballs in the release, then we don't have trouble. In other words:

If 3.4.1-Release is this:
http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/
it has never been broken.
If it is only this:
http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/main/

Then the release is unbuildable on it's own.


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

I will address the Category-B + patches issue on another email.



Mime
View raw message