I have been running similar tests for calc files(the TEST_BUG_FILES) case already before the 3.5 and the 4.0 releases and fixed these crashes with Eike and Kohei before the releases. However this work was done half manually inside of an “unit” test and as soon as it crashed I had to restart the test. As a result of this complex setup it took me between 4 and 6 days to import all 6000+ calc documents. Back then I already had the idea that this task could be automated and moved to a TDF server.

I already tried to convince someone at the Munich hackfest to write such a script as an Easy Hack but had to wait till December until Joren picked up the task. Based on convwatch.py he implemented the first version that has undergone several iterations now and can be found in the Libreoffice dev-tools repository. The script is still looking quite ugly as I have been only adding code and it still contains a large number of debug output for me but the current version should work fine against current Libreoffice master.

After several toolchain problems, one needs a libstdc++ created with at least Linux binutils 2.23.52.0.1 or newer, I finally published the results of the current test run at the Libreoffice developer mailing list. In my latest test run I had a collection of a bit more than 24500 documents with the file extensions cdr, doc, docx, fodg, fodp, fods, fodt, odg, odp, ods, odt, ppt, pptx, pub, rtf, vdx, vsd, wpd, xls, xlsx. While 60 crashes might sound like a lot one has to remember that many of these crashes will never be seen by users. The test is run with a dbgutil build which means that we enforce the exception specification, we switch the standard library to the gcc debug library which has additional assertions and some crashes are related to the special set up of the test. Nevertheless we are planning to fix all these crashes and use the script as part of our automatic testing.

And finally a special thanks to the amazing Libreoffice community who was incredibly supporting in realizing this crazy concept.

Of course the main reason for contributing to Libreoffice is our amazing community. I started about 2 years ago working on Libreoffice when the project was still very young and Oracle required a copyright assignment. However in the Libreoffice community I was immediately welcome and got amazing help, encouragement and found great new friends. It is this community that I want to support and not another project that is spreading rumors and tries to undermine our community.

No company is dominating the development process
Another major point is that I don’t trust the big company in the background of the other project asking for the re-licensing. In my opinion it just feels wrong if a single company is more or less dominating the development of an open source project without even revealing its plans or making clear which of the members are actually being paid for their work on the project. At TDF we have rules that limit the influence of a single company in the Board of Directors and the Engineering Steering Committee. We keep track of the employer and even for single developers these information are kept in our wiki. Our regular commit stats show that not a single company is dominating the development.  This independence from a single company and the transparency are one of the great achievements of TDF and I don’t plan to support a project that is not following similar rules.

TDF as organization
In my last point I already indirectly mentioned another feature of the Libreoffice community. The Document Foundation, as meritocratic foundation, provides a stable environment around the Libreoffice community. Through the foundation we can concentrate on our main task: Making the best office suite. Compared to other office suites that are part of larger foundations TDF’s main goal is providing support to the Libreoffice community and therefore neither the development community nor any other part of the project has to adapt to an external set of rules. Additionally all legal entities of TDF (Board of Directors and Membership Committee) are elected by a STV election from all members.

Amazing framework for developers
So lets finally come to some development related topics. The Libreoffice project provides an incredible framework of tools for developers. I’ll try to list the most important ones with links but I will surely miss some of our cool toys. So lets begin with one of the most important tools, git as version control system, allowing our high commit volume with more than 1500 commits per month to the main development branch ( that does not include commits to the stable branch ). Additionaly we have now gerrit which allows easy review of patches and makes it as easy as possible for new developers so commit their first patch. Tinderboxes building Libreoffice automatically several times a day and automatically notifying all committers who are possibly guilty of breaking the build (While writing this blog post 12 machines are building the master branch with different settings on several platforms: Linux (with clang and gcc), Mac, Windows, Android, iOS).  Let’s not forget being able to crosscompile from Linux to Windows.  This allows quickly to build for the Windows platform without needing to set-up a new virtual machine or worry about our difficult build process on Windows. In the last 2+ years of the project we have cleaned the code from ancient container structure and old string classes, introduced cleaner string handling, transformed nearly our whole build system to gbuild and have done many more clean-ups that are invisible to the user. These improvements are not directly visible but will allow us in the future to focus on the difficult problems instead of worrying about technical debt. Other great tools that developers use every day are automatic bugzilla notifications for bug fixes, static source code analysis reports, a compiler plugin for refactoring, gdb pretty printers, a large set of automatic tests with test coverage reports and much more. I’m sorry for every missing tool in my list. And last but not least one of the coolest things we have are our easy hacks.  They allow new contributors to start with a small task and an assigned mentor and are a great way to help new developers getting started.

So I believe that supporting the Libreoffice project is a good way to support the FOSS community. However I will not agree with people suggesting that re-licensing your commits for another project is a good idea. The Libreoffice project has chosen a free and open source license and anybody implying that refusing to re-license commits is against the FOSS ideas or trying to force developers to re-license by threatening that the changes will be otherwise rewritten disqualifies for any further discussions. In my opinion similar tactics are used by some of our closed-source competition and I feel ashamed that I know about a project using these in the open source world. Respecting the license of a project is a key part of open source development.

Finally I’d like to thank all members of the community who make working on Libreoffice so much fun.

The changes against 1.13.0 are rather small:

• a fix for a crash happening when mixing different gcc versions and demangling fails (fdo#52539)
• using portable way to include header for free (fdo#52536)

Thanks especially to Andriy Gapon for the bug reports and the bug fix.
Please report all bugs you find with this release to bugs.freedesktop.org under the Libreoffice component.

But what are color scales and data bars?
Color scales and data bars are a cool way for spreadsheet users to quickly visualize a set of cells. Color scales allow users to automatically color a range of cells depending on their value. In contrast to normal conditional format you no longer need to specify all colors and the corresponding value, instead you can just specify the start and end point and the corresponding color and Calc will calculate the value of each cell automatically.

Data bars however are a bar inside a cell that makes it extremely easy to visualize the amount a cell value represents relative to the other cells.

But enough with this technical talk. A picture shows more than 1000 words. This screenshot shows the fictitious sales of 4 sales person during one week and uses color scales to highlight the sales per day and uses a data bar to highlight the weekly sales.

I hope you agree with me that these visual helps make it easier for anybody to see the central points  inside all these values. Now you no longer need to study each single value,  the visualization of the values will already help you understand the central points of the spreadsheet without the need of studying all details of the spreadsheet.

And what will be added in Libreoffice 3.7?
In Libreoffice 3.7 I will add some more features. Currently already implemented are AutoMin and AutoMax for data bars. These make it much more easy to control the form of the data bar. AutoMin is just a short version for the Minimum of zero and the smallest value of the range and AutoMax as maximum of zero and the largest value of the range.

In a current master build you can also already test the new export of color scales and data bars to XLSX, we even support the advanced data bar features that Microsoft introduced with Excel 2010.

Another big feature for 3.7 will be the possibility to overlap different conditional formats and if I find some time I would like to improve the new conditional format dialogs. They are not as nice as they should be because the design proposal of our amazing UX team needs these overlapping conditional formats.
Also some performance improvements are already integrated into master or will be implemented soon.

There are some highly user visible topics like the color scales and data bars we added to 3.6 and some nearly invisble work like reworking the cell note storage.

I’ll start with the color scale and data bar rework for 3.6 and some of my changes for 3.7 and then go on with my other work I did in the last months.