Stuff Michael Meeks is doing

This is my (in)activity log. You might like to visit Collabora Productivity a subsidiary of Collabora focusing on LibreOffice support and services for whom I work. Also if you have the time to read this sort of stuff you could enlighten yourself by going to Unraveling Wittgenstein's net or if you are feeling objectionable perhaps here. Failing that, there are all manner of interesting things to read on the LibreOffice Planet news feed.

Older items: 2021: ( J F M A M J J A S O N D ), 2019, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html


LibreOffice progress to 4.2.0

Today we release LibreOffice 4.2.0, packed with a load of new features for people to enjoy - you can read and enjoy all the great news about the user visible features from so many heroic contributors, but there are of course also some contributors whose work is primarily behind the scenes, in places that are not so easy to see - but is still vitally important to the project. It can be hard to extract those from the over twelve thousand commits since LibreOffice 4.1 was branched, so let me expand:

User Interface Dialog / Layout

The UI migration to Glade layout based XML files continues apace with contributions from many individuals, we managed to convert another 280 dialogs in this release, getting us around 70% of the way there. Many thanks to: Caolán McNamara (Red Hat), Manal Alhassoun (KACST), Olivier Hallot (EDX), Faisal M. Al-Otaibi (KACST), Laurent Balland-Poirier, Efe Gürkan Yalaman, Krisztian Pinter, Jan Holesovsky (Collabora), Andras Timar (Collabora), Cao Cuong Ngo, Gergo Mocsi, Katarina Behrens, Abdulmajeed Ahmed (KACST), and Alia Almusaireae (KACST). Thanks also to our translators who helped in the migration of strings.

Graph of progress in UI layout conversion

If you'd like to get involved in driving this to 100%, checkout Caolan's howto and updates.

Build improvements

We've improved a lot this cycle in terms of buildability, and ease of comprehension - important for new contributors.

Much improved compile/run cycle

Six months ago we reported the great news of a pure gnumake build which is faster and sweeter. To compound the goodness for 4.2 we worked hard to ensure that you can compile and then just run LibreOffice without a slow install phase directly after compiling. We build a live, run-able image into instdir/, so:

./autogen.sh
make
cd instdir/program
./soffice -writer
Is enough to get a fully working suite on Windows, Mac or Linux. That avoids a ton of perl, cleans up a lot of scp2/ and includes removing a chunk of install-time setup. Thanks to Michael Stahl (Red Hat), David Tardon (Red Hat), Matus Kukan(Collabora) and Marcos Paulo de Souza. It's always fun to see partners exchanging runnable Windows installs as an instdir.zip.

As an added bonus we also removed some vile platform specific sub-directories from the build infrastructure things like unxlngi6.pro all over the place; if people want to build multiple platforms from the same source they can run configure from a separate directory. Thanks to Michael Stahl (Red Hat), and Tor Lillqvist (Collabora).

Individual localisation builds

Building the large number of localisations that go with LibreOffice - we support 100+ languages out of the box creates quite a compile-time load. Thanks to Bjoern Michaelsen (Canonical) - we can now compile localisation separately from the main package. This helps Linux packagers in multiple ways. The split lowers the requirements for disk space on the build machine (which can be over 25 GB for a release build), which is helpful for porting to more constrained architectures. Builds and respins are faster. With the in-place runnable LibreOffice build into instdir we can also avoid using crufty scp2/ macros interpreted by perl to package these directly. The change also makes it easier to re-spin security fixes without re-building hundreds of unchanged localizations, we look forward to Linux distributions picking this up to ease their packaging and maintenance burden.

Autodoc is dead, long live Doxygen

For many years, horrible hacked version of ... now thanks to Michael Stahl (Red Hat)'s great work doxygen has been taught about LibreOffice's UNO IDL and we've rid ourselves of the cosv, udm and autodoc top level modules - good riddance to 57k lines of code. Thanks also to those who helped to improve, cleanup and 'doxygenize' code comments in 4.2 Julien Nabet, Miklos Vajna (Collabora), Christian Lohmaier (TDF), Thorsten Behrens (SUSE), Stephan Bergmann (Red Hat), Zolnai Tamas (Collabora). You can read our generated documentation for: public API and internal API here.

Code quality work

There has been a lot of work on code quality and improving the maintainability and cleanliness of the code. Another 80 or so commits to fix cppcheck errors thanks to Julien Nabet, the daily rumble of building without any compile warnings with -Werror -Wall -Wextra on each platform with thanks primarily to Tor Lillqvist (Collabora) and Caolán McNamara (Red Hat).

Coverity scan

We have been chewing through the huge amount of analysis from the Coverity Scan, checkout the recent Spotlight Report on LibreOffice. We've seen 210 fixes (and many more closed tickets) in this release alone with many thanks to Caolán McNamara (Red Hat), Eike Rathke (Red Hat), Julien Nabet, Norbert Thiebaud, Andrzej Hunt (Collabora), Markus Mohrhard (Collabora) and Gergo Mocsi

Import and now export testing

Thanks to Markus Mohrhard we have the successful import crasher tests, that now test 45,000+ problem / bug documents from bugzillas across every project we can get our hands on. We load them one by one in a build with paranoid debugging assertions turned on. In recent times, we've also started exporting these documents to multiple different file formats looking for export issues, then, subsequently running whatever validation tools we can on the output. That, over time has a great impact on quality. Output is logged by git hash.

Valgrind fixes

Valgrind continued to be a wonderful tool for finding and isolating leaks, and poor behavior of various bits of code. Thanks to Mark Wielaard for fixing a number of leaks and other problems here, along with many other of the usual suspects.

Unit testing

We also built and executed more unit tests with LibreOffice 4.2 to avoid regressions as we change the code. These are rather hard to measure, since people like to pile up new tests inside existing unit test modules. One simple measure is to grep for the CPPUNIT_TEST() registration macro we can see that we added 216 of these since 4.1 - but we also added more CPPUNIT_ASSERTs per test; over 2160 of these. Our ideal is that every bug that is fixed gets a unit test to stop it ever recurring. With over 80 committers to the unit tests in 4.2, it is a little difficult to list everyone involved here, but it's wonderful to have a firmly entrenched and growing culture of writing unit tests alongside fixes.

Graph of number of unit tests and assertions
QA / bugzilla

This release the QA team has grown, and done some amazing work both triaging bugs, and also closing them. Thanks to Bjoern Michaelsen (Canonical), Robinson Tryon and Joel Madero for doing some great work there - and particularly to our top bug fixers, there is a great list of people responding in bugs here.

One metric we watch in the ESC call is who is in the top ten in the freedesktop Weekly bug summary. Here is a list of the top twenty people who have appeared most frequently in the weekly list of top ten bug closers; thanks to them tommy27, Caolán McNamara (RedHat), Maxim, Jean-Baptiste Faure, Eike Rathke (RedHat), ign_christian, Foss, Urmas, Joel Madero, Cor Nouws, Julien Nabet, Michael Stahl (RedHat), Maxim Monastirsky, Jorendc, Andras Timar (Collabora), Lionel Elie Mamane, Kohei Yoshida (Collabora), mariosv, bfoman, Thomas Arnhold, Adolfo Jayme (fitoschido), Sophie (TDF), Samuel M., Markus Mohrhard (Collabora), Rob Snelders.

You can read more about bug statistics and background on Bjoern's (interesting) blog (with cats). The overall bug picture can be summarised with some thousands though.

Code cleanup

Code that is dirty should be cleaned up - so we did a lot of that.

The final death of UniString

Perhaps the largest single change in 4.2 which has been underway from the very beginning of the LibreOffice project is removing our obsolete tools/ string class - thus leaving us with only 2x string classes, one for arbitrary encoding 8bit strings, and another for UTF-16 strings. The final commit slayed this monster for good. But of course huge numbers of people have worked hard at this job and associated cleanups for several years now - in this release around thirty people lent a hand; thanks particularly to Noel Grandin for spearheading the work, but also to many others Matteo Casalin, Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Ivan Timofeev, Michael Stahl (Red Hat), Thomas Arnhold, Kohei Yoshida (Collabora), Eike Rathke (Red Hat), Tor Lillqvist (Collabora), Palenik Mihály, Markus Mohrhard (Collabora), Luboš Luňák (SUSE), MÁTÉ Gergely, Andrzej J.R. Hunt (Collabora), Christina Rossmanith, Laurent Balland-Poirier, Julien Nabet, Sean Young, Neil Moore, Jelle van der Waa, Donizete Waterkemper and Arnaud Versini.

Finally in 4.3 we will have the first user visible benefit of this work, allowing more than 64k characters in a single paragraph, checkout our still nascent 4.3 features wiki page and a related blogpost. Beyond that, fixing a bug recently it was somewhat interesting to see the morass of string types in the Windows platform.

One fewer temporary file API

We have a number of APIs for handling temporary files with different pedigrees, the oldest and ropiest: tools/tempfile.hxx was kindly written out by Palenik Mihály. Ideally there would be just one (safe) place in sal/ where temp files are handled.

Ongoing German Comment redux

We continued to make some progress on translating our last lingering German comments across the codebase to good, crisp technical English. Many thanks to Philipp Weissenbacher, Philipp Riemer, Laurent Balland-Poirier, Rolf Hemmerling, Chris Hoppe, Rodolfo Ribeiro Gomes, Matthias Freund and Henning Diedler. I suspect the tailing off effect is in part due to a rather substantial number of false positives in our language-guessing bin/find-german-comments tool.

Graph of remaining lines of German comment to translate
Removing dead code through compiler warnings

Lots of dead code was identified (and purged) with the help of recent improvements in Clang/GCC warnings (-Wunsued-function, -Wunused-variable, -Wunused-private-field, etc.) and by using SAL_WARN_UNUSED. (Caolán McNamara (Red Hat), Luboš Luňák (SUSE), Stephan Bergmann (Red Hat), Tor Lillqvist (Collabora))

Windows build & debug wins

The windows build time was reduced by 10 minutes (10% or so) thanks to Bjoern Michaelsen (Canonical) and then promptly slowed down again by adding Link Time Optimisation into the mix for newer Microsoft compilers.

Another much requested feature that helps users to provide excellent stack traces for Windows crashes and hangs, and thus debug / fix those much more rapidly is Cloph's Windows Symbol Server for release builds. Checkout how to get a backtrace - which is a wonderful way for users to provide better bug reports on that platform. Thanks to Fridrich Štrba (SUSE), Luboš Luňák (SUSE), and Christian Lohmaier (TDF).

Calc core refactoring

There is so much to say here, and it will be presented in much more detail shortly at FOSDEM. Suffice it to say that Calc has had a massive internal re-work, improving memory usage, performance in many cases, allowing the use of OpenCL to calculate some formulae on the GPU and more. Many thanks to Kohei Yoshida (Collabora), Markus Mohrhard (Collabora), and to the team from MultiCoreWare: I-Jui (Ray) Sung, Hao Chen, Shiming Zhang, Yiming Ju, Yang Zhang, Hongu Zhong, Ming Li, Min Wang, De Chuang, Feng Zheng, mulei, Xin Jiang, Zhenyu Yuan and more.

Getting involved

I hope you get the idea that more developers continue to find a home at LibreOffice and work together to complete some rather significant work both under the hood, and also on the surface. If you want to get involved there are plenty of great people to meet and work alongside. As you can see individuals make a huge impact to the diversity of LibreOffice (the colour legends on the right should be read left to right, top to bottom, which maps to top down in the chart):

Graph showing individual code committers per month

And also in terms of diversity of code commits, we love to see the unaffiliated volunteers contribution by volume, though clearly the volume and balance changes with the season, release cycle, and time available for mentoring:

Graph of number of commits per month by affiliation

Of course, we maintain a list of small, bite-sized tasks which you can use to get involved at our Easy Hacks page, with simple build / setup instructions. We now have a cleaner, and safer environment to work on improving the code. For example this video that shows how easy it is to get started in LibreOffice development these day. It is also encouraging to see how the Easy Hacks are progressing, lots of them are getting closed - could you close the 400'th ?

Graph of progress closing easy hacks over time

Another thing that really helps is running pre-release builds and reporting bugs just grab and install a pre-release and you're ready to contribute alongside the rest of the development team.

Conclusion

LibreOffice 4.2 is the next in a series of releases that incrementally improve not only the features, but fundamentally the foundations of the Free Software office suite. Of course, it's only the first in a long series of monthly 4.2.x releases which will bring a stream of bug fixes and quality improvements over the next months.

I hope you enjoy LibreOffice 4.2.0, thanks for reading, and thank you for supporting LibreOffice.

Postscript: this item kindly translated to French.


My content in this blog and associated images / data under images/ and data/ directories are (usually) created by me and (unless obviously labelled otherwise) are licensed under the public domain, and/or if that doesn't float your boat a CC0 license. I encourage linking back (of course) to help people decide for themselves, in context, in the battle for ideas, and I love fixes / improvements / corrections by private mail.

In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.

Michael Meeks (michael.meeks@collabora.com)

pyblosxom