[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 1.3.0 RC1

From: David Anderson <david.anderson_at_calixo.net>
Date: 2005-10-23 03:33:55 CEST

Okay, another update. For the busy ones among you, looks like the RC
won't roll until Monday at the earliest, and there is stuff to review

Now, for details. Today, thanks to Max Bowsher's thorough reviewing,
we found that our previous fixes to the SWIG bindings breaks them on
64 bit architectures. Whoops. We've spent the day fixing these up,
and have now filled STATUS with fixes to both SWIG and the build

I've rolled a test tarball which includes all the nominated changes,
and built it successfully on my own system (x86_32) and on a friend's
system (x86_64). So, with all the changes in STATUS merged, the build
is no longer broken.

However, there are still SWIG issues because of this 32/64 bit thing.
The problem is that as we now precompile SWIG interfaces at release
time, we must defer all arch decisions to the actual compilation of
the generated C files. This is not impossible (see today's IRC log
and the nominated changes for proof), but requires some fixes, because
we didn't pay any attention to this before now.

David James has been busy fixing some of this, so here is the current
status of our SWIG bindings, tested on the two test architectures I
had (x86_32 amd and x86_64 amd64):

  * Python builds and passes tests on both.

  * Perl builds on both, passes tests on x86_64. On x86_32, one of
    the tests in 5delta crashes. This is a blocker for the RC, and so
    we need someone who understands the perl bindings to fix it and
    nominate it for the release branch.

  * Ruby builds on both. Three tests fail on both architectures (the
    same tests fail). I've mailed Kouhei to ask him to take a look at
    this and call whether this is a blocker or not.

I have not yet dared to run the non-bindings test suite on the
tarball, I'm afraid. According to our automated test boxes,
everything is cool, but, well... According to it, our release was
also going to be cool :-).

There. So, what we now need:

  * People to vote on the numerous items in STATUS. The release
    tarball doesn't build without all of these.

  * Someone to look at the breakage we caused in the Perl bindings on
    x86_32, and sort it out.

  * Kouhei (and/or others) to look at the Ruby bindings problems, and
    tell me whether this is a critical blocker or whether we can roll
    without fixes (reminder: the Ruby bindings are still considered
    experimental as of this release). Oh, and get those fixes
    commited and nominated, of course :-).

  * A lot of cafeine.

This pushes the RC back until at least Monday, if not further. Sorry
for the yet-another-delay, but these arch problems went on undetected
by our test suite (shouldn't the boxes be running check-swig-* instead
of just swig-*, to catch failing tests as well as failing compiles?),
and so we're getting to fix them all now, at release time. It sucks,
I know, but we're working on it, and welcome all the help we can get.

If anyone needs access to a 64 bit box for testing, I can provide
access to a common (common to all svn developers who request access
that is) account on a friend's amd64 that can compile svn and its
bindings. Just mail me your SSH public key, and I'll mail back
instructions to shell in.

There, that's about it. Unless there is more catastrophic
development, I'll be doing stuff other than Subversion release
shepherding tomorrow (hey, I'm on weekend too!), but should stay
pingable by mail or irc, if something comes up.

Thanks all, for the help fixing the problems and your patience.
Almost there now, for the third day running. Surely it can't be
*that* far off now?!

- Dave.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 23 03:47:18 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.