It is normally a rule for the community not to do any big and potentially risky changes in OpenOffice.org months before release. UI-freeze, feature-freeze are dates that if you miss them, your feature or fix will have to wait for the next release, or eventually for OOoLater tag. This is always true ...
... unless you are not the community member, but Sun employee. In that case, the rule starts to be a more flexible one.
To cut the thing short, if you are community member and are building ooo310-m11 with Windows and cygwin (and maybe only with Visual Studio 9, which is what Sun uses), you will realize that something changed and your build will consistently crash in the python module. The binary that will crash is the vcbuild.exe binary. What happened? Just our friends from Sun upgraded the python version of OpenOffice.org from 2.3.4 to 2.6.1 between release candidate 1 and release candidate 2. Theoretically, only show-stopper fixes are allowed in the RC phase, but since the rule is flexible depending on which side you are sitting, this could happen.
So, if you are on the wrong side of the flexibility, here is what can bail you out:
--- python/makefile.mk 2009-05-05 08:58:50.745625000 +0200
+++ python/makefile.mk 2009-05-05 08:59:45.261250000 +0200
@@ -117,11 +117,7 @@
# Build python executable and then runs a minimal script. Running the minimal script
# ensures that certain *.pyc files are generated which would otherwise be created on
# solver during registration in insetoo_native
-.IF $(SYSBASE) != ""
-BUILD_ACTION=$(COMPATH)$/vcpackages$/vcbuild.exe -useenv pcbuild.sln "Release|Win32"
-.ELSE
BUILD_ACTION=$(COMPATH)$/vcpackages$/vcbuild.exe pcbuild.sln "Release|Win32"
-.ENDIF # $(SYSBASE) != ""
.ENDIF
.ENDIF
But given the way this was rushed through, don't be surprised if you have other problems later.
BTW, it is not like this problem was not known about beforehand.
Game, set, match for "Quality through process" approach.
UPDATE:
As pointed out on IRC, it is true that many people worked hard to make this - as agreed necessary - change possible at the late stage. I did not intend to offend them and stand to be corrected. The point here is that such changes are pretty risky at the late stage of release cycle especially because upstream does not use the same build environment as community. In the times where I was still bothering to push updates for libwpd upstream, I was often a victim of many procedural hickups. So, seeing a fast-track risky change in last moment is reminding me of all the hours fighting the bureaucracy. But, again, not intending to offend anybody.
