incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer ...@a-w-f.de>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Fri, 01 Jun 2012 14:46:10 GMT


On 01.06.2012 14:03, Rob Weir wrote:
> On Fri, Jun 1, 2012 at 3:17 AM, Andre Fischer<af@a-w-f.de>  wrote:
>> On 31.05.2012 18:12, Rob Weir wrote:
>>>
>>> On Thu, May 31, 2012 at 11:19 AM, Andre Fischer<af@a-w-f.de>    wrote:
>>>>
>>>> On 31.05.2012 14:51, Rob Weir wrote:
>>>>>
>>>>>
>>>>> On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni<pfg@apache.org>
     wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- Mer 30/5/12, Rob Weir<robweir@apache.org>      ha scritto:
>>>>
>>>>
>>>>
>>>> [...]
>>>>
>>>>
>>>>> So instead of a an axe, let's try a scalpel.  The ext_sources tree was
>>>>> branched along with the rest of the the AOO 3.4 tree.  So you should
>>>>> be able to safely work on the branch, defining the external
>>>>> dependencies there.  This could be done without touching the trunk and
>>>>> without breaking the 3.4.0 release.  Then, after 3.4.1 is released, we
>>>>> can bring those changes to the trunk.
>>>>>
>>>>> Does that make sense?  We don't break our release distributions until
>>>>> we have a working replacement in the form of 3.4.1.  If that means we
>>>>> delay graduation until 3.4.1, then so be it.
>>>>
>>>>
>>>>
>>>> You are talking about a new branch, right, not the 3.4.1 branch?
>>>>
>>>
>>> I thought the 3.4.1 branch would be appropriate.  Move the category-b
>>> tarballs to Apache Extras, and make the build fetch from there instead
>>> of from SVN.  That way the trunk's copy of these dependencies doesn't
>>> disappear yet.  Then when we release 3.4.1, we have a release that is
>>> not dependent on the SVN copies, and we can safely remove them then.
>>
>>
>> My understanding is that we have to make sure that the files referenced by
>> the (source) release do not go away.  That did not work so well for the 3.4
>> release because they where referenced on trunk.  If the 3.4.1 release
>> references the files on the branch then that should be safe(r).
>> Trunk is where the main part of development takes place.
>>
>
> In an ideal world, yes.  We would never break the AOO 3.4.0 release
> source package.  But one compromise could be to first relocate the
> cat-b tarballs for 3.4.1 release.  And once that release is made, then
> do the changes that would break the 3.4.0 source package.
>
> If we do this then we ensure that the latest source distribution can
> always build.

Maybe you are right.  May resistance against such changes in 3.4.1 comes 
from the rules we had at Sun/Oracle: only fix severe bugs and not 
introduce new regressions.

Anyway, I am working on the changes to fetch_tarballs.sh:

- The conversion to a Perl script is already done (it is already notably 
faster on Windows when no packages have to be downloaded)

- I can specify multiple download sites for each file.  The majority of 
tar balls can be downloaded from their original servers.

- Fallback download server will be Apache Extras.

I hope that the work will be finished by Monday.

-Andre

>
>>
>>>
>>> The problem we have now is that even though we branched after the 3.4
>>> release, the build script is still fetching from the trunk copy of the
>>> dependencies.  So we need to fix this is a somewhat backwards way.
>>
>>
>> For the 3.4 release we have to restore the tar-balls that where deleted
>> since the release.  That does of course not mean that the newer versions
>> have to be removed as well.  Due to different version numbers and MD5 sums
>> they have different names and can coexist.
>>
>> -Andre
>>
>>
>>>
>>> Or am I missing something?
>>>
>>> -Rob
>>>
>>>> -Andre

Mime
View raw message