<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 5:18 PM, Michael Meeks <span dir="ltr"><<a href="mailto:michael.meeks@collabora.com" target="_blank">michael.meeks@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
* Windows XP deprecation for 5.2 story ? (Cloph)<br>
+ goal - to have the baseline be based on Windows Server 2016, and VS 2015<br>
+ unclear if builds created with this combination will run on WinXP<br>
+ Thorsten had a stackoverflow comment saying it should work.<br>
+ just giving warning that if there are big hassles with WinXP API etc.<br>
we may drop it for 5.3 and onwards.<br>
+ no real reason to drop it as a platform for now.<br>
+ just want to give the advanced warning that it may go sooner (Norbert)<br>
+ sob stories about old / stolen WinXP (Heiko)<br>
+ no sympathy - if running a 10 year old OS, can run old LibreOffice (Norbert)<br>
+ this is a meritocracy, who does the work chooses (Norbert, et. al)<br>
+ even if we did remove it - always room for volunteers to make their own builds (Bjoern)<br>
+ but no news here: we continue as before (Michael)<br></blockquote><div><br><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
* Crashtest update (Caolan)<br>
+ 1 import failure, 7 export failures, coverity pending<br>
+ discovered there was a timeout, throwing an assert after 2 minutes<br>
an issue on the crash-testing box, but not when tested.<br>
+ marketing numbers of 0.00 for coverity correct as of last testing cf. 5.2 branch<br>
+ database documents being round-tripped (Michael S)<br>
+ had a tendency to deadlock - 10% of them.<br>
+ ended up being killed by the python script: didn't result in a crashlog.<br>
+ only get an entry in the crashlog if we get a dispose exception.<br>
+ have a fix for that; to introduce in the database document the<br>
solar mutex for locking<br>
+ another potential gift that will give and give.<br>
+ crash test now runs without deadlocking<br>
-> can we fix the python script - to report hangs ? (Michael)<br>
+ some where writer has an infinite layout loop (Michael S)<br>
+ should these be reported in crash-testing ? not sure.<br></blockquote><div><br></div><div>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.<br></div><br></div><br><br></div></div>