Posted on

The Lifecycle of LibreOffice Bugs

As developer of Gnumeric, during the interoperability testing of new Gnumeric features I often encounter LibreOffice bugs. In the past I tried to report all such bugs to LibreOffice since I would appreciate similar service from the LibreOffice developers. Over time I have come to recognize that the typical lifecycle of a LibreOffice bug differs greatly from that of a Gnumeric bug:

  1. Bug reporter files a bug report with all neccessary information.
  2. Optionally a significant amount of time later the bug is closed or requests more info since the LO developer looking at the report does not know of the existence of an ODF specification and is unable to look into the ODF file without opening it in LibreOffice.
  3. Optionally another person realizes that the bug as reported is in fact valid and the report complete.
  4. The bug is ignored for 6 months to one year.
  5. The bug status is changed to NEEDINFO with the following (or similar) notation added:

    "This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
    started right out as NEW without ever being explicitly confirmed. The bug is
    changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
    to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2
    prereleases.
    Details on how to test the 3.5.0 beta1 can be found at:
    http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1
    more detail on this bulk operation:
    http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html"

  6. Half a year later the bug is closed with the notation:

    "Due to the fact, that there are a lot of NEEDINFO bugs with no answer within
    the last six months, we close all of these bugs.
    To keep this message short, more infos are available @
    https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
    Thanks for understanding and hopefully updating your bug, so that everything is
    prepared for developers to fix your problem."

Of course the problem at hand wasn't really my problem but LibreOffice's problem.

I guess in future I will save myself lots of time by not filing these bug reports in the first place.

Just for reference, the following are example bugs that have this or a similar life cycle:

Posted on

Designed Incompatibility

In certain circles, Microsoft is usually blamed for "extend, embrace, extinguish" where the "embrace" stands for purposefully changing a specification to create incompatibilities. This post is not addressing Microsoft but another group that is usually more standards compliant: the Apache Foundation.

In the release notes of the new Apache OpenOffice release, changes to the TIME function are advertised:

Spreadsheet: TIME function returns values 00:00:00 <= x <= 23:59:59.999
The TIME spreadsheet function returns values between 00:00:00 and 23:59:59.999... inclusive and wraps values equal to or greater than 24:00:00.

It is easy to verify that Apache OpenOffice saves this function as the ODF OpenFormula function TIME:

<table:table-cell table:formula="of:=TIME(48;0;0)" office:value-type="time" office:time-value="PT00H00M00S"><text:p>00:00:00</text:p></table:table-cell>

This means that normally this function should be compatible with the ODF 1.2 part 2 specification as outlined in 6.10.17, where it says:

Syntax: TIME( Number hours ; Number minutes ; Number seconds )
Semantics: Returns the fraction of the day consumed by the given time, i.e.: ((hours*60*60)+(minutes*60)+seconds)/(24*60*60)
Hours, minutes, and seconds may be any number (they shall not be limited to the ranges 0..24,0..59, or 0..60 respectively).

So ODF requires TIME(48;0;0) to evaluate to 2, while in the new Apache OpenOffice it evaluates to 0.

Note that this is the value calculated, depending on the cell format this value could look differently.  Both LibreOffice and Gnumeric evaluate TIME(48;0;0) as 2, but LibreOffice shows it as 48:0:0 while Gnumeric shows it as 00:00.