Skip navigation

Monthly Archives: April 2009

Let There Be Summer!

Following the original announcement, more than 70 students applied to the Go OpenOffice project for the Google Summer of Code. I was truely impressed, and want to say “thank you!” to all that took the sometimes considerable effort to write a good application.

2009-summer-of-code-logo-final-r3-01

Choosing six projects among those many was not easy; but I think the collective mentors did an outstanding job selecting both excellent students and relevant tasks – so I’m happy to announce this year’s Go OpenOffice GSoC participants (in order of their last name):

Andrés Correa Casablanca will work on performance improvements

Jesús Corrius will have Win32 OOo cross-compile under Linux

Maja Djordjevic will add Hyperlink/Reference navigation buttons

Dona Hertel will extend the functionality of the templates in Impress

Tzvetelina Tzeneva will improve OOo Writer’s document comparison

Jonathan Winandy will add an Ocropus OCR integration to OOo

Yay to the successful applicants!

To all those who applied, but have not been selected: the competition was fierce, I can assure you, so don’t be put off, try again next year – and maybe give yourself this extra bit of a head start and continue working on OOo! We’ll always and happily mentor you, if you’re enthusiastic and willing to learn – just come and ask us, you already know where!

That only leaves me to thank Google for sponsoring us; thanks to all who applied, thanks to the mentors – without you folks, all of this just won’t happen! Looking forward to a wonderful summer 2009!

Advertisement

How OpenOffice.org will switch to a DSCM

With the recent survey about the community’s favorite distributed software configuration management system completed, the Engineering Steering Committee went into debating the candidate system’s merits. Since there was a draw between mercurial and git (which of course counts double because of extra coolness), the ESC came to this very Solomonian decision: proportional to vote turn-out and coolness coherency, the OOo source tree will be split into four different repositories, each hosted by the respective DSCM prospect, in the following way:

dscm hg (with 49%) gets 48% of code:
 helpcontent2 officecfg binfilter sd ooo_custom_images sysui chart2 
 wizards instsetoo_native framework odk icu writerfilter dmake psprint_config
 redland toolkit scripting xpdf bitstream_vera_fonts libxml2 basctl openssl 
 lotuswordpro libxslt stoc fpicker cppu comphelper accessibility uui basegfx 
 package rsc external rhino xmlhelp ucbhelper cppcanvas crashrep registry soltools
 lingucomponent hwpfilter jvmfwk lpsolve io basebmp sax hyphen embedserv 
 pyuno writerperfect i18nutil xml2cmp libwps remotebridges rdbmaker jut 
 postprocess sccomp twain offuh fileaccess MathMLDTD

dscm none (with 25%) gets 24% of code:
 svx sw dictionaries offapi dbaccess vcl sal xmerge vigra desktop xmloff scaddins 
 cairo scp2 jfreereport solenv readlicense_oo autodoc ucb bridges tools stlport 
 hsqldb canvas setup_native psprint shell saxon reportbuilder jurt cppuhelper dtrans
 swext codemaker curl testtools scsolver xmlscript javaunohelper sot ridljar 
 external_images icc idlc testshl2 hunspell beanshell idl jpeg UnoControls unoil 
 mdbtools epm regexp salhelper libwpg jvmaccess ure animations expat fondu 
 unixODBC x11_extensions eventattacher sane

dscm git (with 23%) gets 22% of code:
 sc qadevOOo default_images svtools boost sfx2 extensions filter i18npool
 connectivity oovbaapi sdext basic python starmath reportdesign configmgr
 oox forms xmlsecurity lucene goodies tomcat slideshow apache-commons 
 udkapi padmin berkeleydb libxmlsec javainstaller2 agg transex3 cli_ure
 config_office automation unotools embeddedobj avmedia libwpd moz linguistic
 store libtextcat unoxml neon bean cppunit cosv Mesa sj2 smoketestoo_native
 sandbox vos unodevtools udm afms cpputools np_sdk zlib o3tl msfontextract
 stax libegg packimages agfa_monotype_fonts

dscm bzr (with 3%) gets 4% of code:
 extras

Where the people that did not prefer any DSCM will get what they asked for, namely no DSCM at all: those modules will stay with subversion (the proposal to not even host them in any SCM, but simply hold one version on a file server, did not get a majority vote).