Revision as of 13:25, 23 August 2015

CI problems

Network tests fail a lot. Proposed solutions to avoid running network tests:
Move QtNetwork into its own git module
- Thiago: Network cannot swapped out into its own module, due to dbus reqiring it in the future
Only run network tests when code affecting QtNetwork has changed -> more likely
Gurantees for VMs
CPU time
Swapping a problem?
Proposed Solution: Give more resources to VM tests. Frederik to take care.
Debugging of Network error causes:
- Rich and Peter to sign NDA with Digia to get VPN access. Tuuka is involved, will start after holidays
CI resources are not well used, getting fixed in the future (Frederik)

The code is horrible (Thiago)
We are not currently testing against SSH (the most common usecase probably), only Dante
The tests have been unstable, will be disabled for now
Rich volunteered to look into it at some point

Tests are disabled
Before, we used Linux machines. Would be nice to also run against Windows Servers to get coverage for Domain credential use.
Digia would get a Windows Server VM up and running, danimo to provide instructions to Frederik

Rich hates the SSL errors API, the design is wrong, sometimes still requires a subeventloop, The concept of "accepting error" is wrong, you accept a chain. On top, there are different errors with different versions of OpenSSL. We need a new API.
The new API would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current API leads to "overacceptance", essentially to SSL errors.
Possbilities for a predefined UI: No single UI will fit all purposes, but we can make it easier by providing a clear API that just needs to be hooked into Widgets/QML.

@@ Line 28: / Line 28: @@
 =<span class="caps">SSL</span>=
-* Rich hates the <span class="caps">SSL</span> errors <span class="caps">API</span>, the design is wrong, sometimes still requires a subeventloop, The concept of “accepting error” is wrong, you accept a chain. On top, there are different errors with different versions of OpenSSL. We need a new <span class="caps">API</span>.
+* Rich hates the <span class="caps">SSL</span> errors <span class="caps">API</span>, the design is wrong, sometimes still requires a subeventloop, The concept of "accepting error" is wrong, you accept a chain. On top, there are different errors with different versions of OpenSSL. We need a new <span class="caps">API</span>.
-* The new <span class="caps">API</span> would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current <span class="caps">API</span> leads to “overacceptance”, essentially to <span class="caps">SSL</span> errors.
+* The new <span class="caps">API</span> would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current <span class="caps">API</span> leads to "overacceptance", essentially to <span class="caps">SSL</span> errors.
 * Possbilities for a predefined UI: No single UI will fit all purposes, but we can make it easier by providing a clear <span class="caps">API</span> that just needs to be hooked into Widgets/QML.