Re: Any chance to merge the gbuild branch rather soonish?
On 05/05/2016 10:51 AM, Damjan Jovanovic wrote: Windows XP SP3 32-bit on a VirtualBox instance on FreeBSD, underlying filesystem is ZFS which does cause I/O slowdown, but not enough to explain this. Can't remember what compiler I installed; there are Windows SDK 7 and Visual Studio 9 directories. Despite the lag, I'd like to get back to this given all your effort so far. Do you still have your config.log? It should show in there what it found for the C compiler. OK, and maybe a crazy idea. Despite the fact that we're having problems with the Win7 build for our usual processing, would it be worth doing a merge INTO the guild branch and setting up an additional win buildbot for that? SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0" ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH" --with-midl-path="$SDK_PATH/bin" --with-ant-home="/cygdrive/c/apache-ant-1.9.6" --with-dmake-url=" http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"; --with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz"; --enable-pch --disable-atl --disable-activex --without-junit --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC" --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0" --disable-directx --with-package-format="installed" --enable-wiki-publisher I am currently thinking we will gain more from porting to Java, than trying to maintain a build system for the buggy, leaky, complex, crash-prone, insecure languages that are C/C++. I don't know if its C++, which is still very widely used for programming development, or our complicated code, of which I'm guessing, at least 25% could be eliminated. On Thu, May 5, 2016 at 7:18 PM, Kay Schenk wrote: On Tue, May 3, 2016 at 12:07 PM, Damjan Jovanovic wrote: Unfortunately I discovered a major problem with the gbuild-reintegration branch: on Windows, the build time of trunk is about 3-4 hours, but it's over 12 hours to build gbuild-reintegration :-(. I don't have time to investigate soon, nor do I know where to even begin... Hi Damjan, and thanks for this update even it is disappointing. Could you share what the specifics are for the Windows platform you're using for the build? * specific Windows OS * C compiler and flags * build options * anything else? Thanks again for all your work on this. We can work this out. On Tue, May 3, 2016 at 5:20 AM, Pedro Giffuni wrote: Hello; FWIW, I am preparing a second round of spelling fixes ... it's a quite big change. I would prefer to do such changes *after* the new build system is in place though. I can deal easily with any breakage caused by the spelling fixes but it may not be very fun to have to fix again the build issues so I would really prefer to chose the battle field ahead of time ;). Pedro. - -- -- MzK "Time spent with cats is never wasted." -- Sigmund Freud -- MzK "Time spent with cats is never wasted." -- Sigmund Freud - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Release Manager for 4.2.0?
Hello all, Any news for this next 4.2.0? - Mail original - De: "Andrea Pescetti" À: dev@openoffice.apache.org Envoyé: Dimanche 27 Mars 2016 22:13:11 Objet: Re: Release Manager for 4.2.0? On 29/01/2016 Andrea Pescetti wrote: > For 4.2.0 we need a Release Manager. I would prefer NOT to be the > Release Manager for 4.2.0 since I'm finding that in this period I can > help more productively with tasks that do not require constant > interaction ... > I am surely available to have a significant role in the 4.2.0 release A few days after writing this, almost 2 months ago, sudden events left me incapacitated to make any significant contributions until very recently. I'm still unable to make long-term commitments. Anyway, there are some issues we need to get done as a team before appointing a release manager makes sense: 1) Enough code. Done. The merge of the recent gbuild work totally justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny fraction of the fixes that (at that time) were available on trunk. So here we are already OK, and we've been OK for months. 2) Localization. I got shell access to the Pootle server a few days ago. I'm still looking around, and if someone else want to join this is an important part. We need to have a solid process for updating translations (the full route: new strings in code -> Pootle -> back to code -> in localized builds) in place. 3) Buildbots and ASF-owned build machines. Buildbots are not essential for a release: 4.1.2 was built (like all previous releases in history) on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we can't use buildbots for it; we need to setup new systems. Those who read the infrastructure@ list can see the discussion I started there yesterday. Still, having buildbots helps QA and having ASF-owned build machines is an important investment for the project: at that point we will be able to make a release within days, not months. We should make as much progress as we can here. Again, if anybody can help, this is an important area. 4) There are several optimizations I have in mind, especially on reducing a bit our binary size on Linux (trust me, it is really a pain to commit all those binaries to SVN, or to any version control system). But they are not essential. I have just committed to the devtools/ area the scripts we (mainly Juergen) used to build the 4.1.2 release, with specs of the build machines. I've had them since last October, but I never committed them. They are a first step if we want to build our release binaries on ASF hardware: they contain build options and config.log to have some more information on the environment. My next priorities will be localization (especially, re-exporting the Italian translation to Pootle and re-importing it) and and a proof-of-concept VM for building releases on Linux (64 bit) based on the above scripts. There is plenty of room for other to jump in (Linux 32, Windows, Mac; or localization management) so please do! Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
