Re: [Libreoffice-qa] minutes of ESC call ...

On Thu, Jul 28, 2016 at 5:18 PM, Michael Meeks <michael.meeks@collabora.com>
wrote:

> * Windows XP deprecation for 5.2 story ? (Cloph)
>     + goal - to have the baseline be based on Windows Server 2016, and VS
> 2015
>         + unclear if builds created with this combination will run on WinXP
>         + Thorsten had a stackoverflow comment saying it should work.
>     + just giving warning that if there are big hassles with WinXP API etc.
>       we may drop it for 5.3 and onwards.
>     + no real reason to drop it as a platform for now.
>        + just want to give the advanced warning that it may go sooner
> (Norbert)
>     + sob stories about old / stolen WinXP (Heiko)
>        + no sympathy - if running a 10 year old OS, can run old
> LibreOffice (Norbert)
>        + this is a meritocracy, who does the work chooses (Norbert, et. al)
>     + even if we did remove it - always room for volunteers to make their
> own builds (Bjoern)
>     + but no news here: we continue as before (Michael)


A side note about that. Both 5.2 as well as 5.1.5 should work much better
and fix the problem around curl on XP. That will bring back support for ucp
providers based on curl and the update check. Based on that experience
unless the toolchain makes it impossible most external libs seem to support
XP through passing the correct XP SDK version in.


> * Crashtest update (Caolan)
>     + 1 import failure, 7 export failures, coverity pending
>     + discovered there was a timeout, throwing an assert after 2 minutes
>       an issue on the crash-testing box, but not when tested.
>     + marketing numbers of 0.00 for coverity correct as of last testing
> cf. 5.2 branch
>     + database documents being round-tripped (Michael S)
>        + had a tendency to deadlock - 10% of them.
>        + ended up being killed by the python script: didn't result in a
> crashlog.
>        + only get an entry in the crashlog if we get a dispose exception.
>        + have a fix for that; to introduce in the database document the
>          solar mutex for locking
>            + another potential gift that will give and give.
>        + crash test now runs without deadlocking
>        -> can we fix the python script - to report hangs ? (Michael)
>            + some where writer has an infinite layout loop (Michael S)
>            + should these be reported in crash-testing ? not sure.

The script was reporting the files it could not open and the files that
took too long. Keep in mind that this not only covers deadlocks and
therefore it was nearly impossible to get anything useful from the results.
It limits all tests for a file (so all the import and then reexport to
different formats to 3 minutes). In theory we could increase the limit and
enable reporting again to reduce the number of false positives but that
will also increase the runtime of the crash testing significantly.