On 01.06.2012 14:03, Rob Weir wrote:
On Fri, Jun 1, 2012 at 3:17 AM, Andre Fischer<a...@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<a...@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<p...@apache.org> wrote:
--- Mer 30/5/12, Rob Weir<robw...@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
