[vlc-devel] [vlc-commits] tests/tls: Disable checks for ALPN on apple platforms

[Rémi Denis-Courmont]

Le tiistaina 1. marraskuuta 2016, 22.37.53 EET David Fuhrmann a écrit :
> > Am 01.11.2016 um 21:47 schrieb Rémi Denis-Courmont <remi at remlab.net>:
> > 
> > Le tiistaina 1. marraskuuta 2016, 18.22.41 EET David Fuhrmann a écrit :
> >> I disabled a test for a distinct feature (...)
> > 
> > You disabled a test for necessary/relied-upon and documented behaviour of
> > the API. This is wrong and needs reverting. Period.
> 
> I do not think 100% ALPN support is „necessary" for VLC. It might be needed
> for full support of HTTP/2, but is definitely not mandatory for HTTP/1.1.
> 
> You documented (cc80d6a2) and added (19e7f0ed) the behavior after the
> securetrcansport plugin was added (673d45d0). So one could argue that the
> documentation is wrong and does not reflect the current state of all TLS
> plugin functionalities.

I recall that Felix promised to keep up with updates. And even if he had not 
or if I recall wrong, it is the MacOS dev's responsibility to maintain MacOS 
speicfic for practical and moral reasons already outlined - like the MacOS 
GUI, like the MacOS VT, etc.

If the MacOS devs don´t want to do that (anymore), you are welcome to remove 
ST, and fallback to the generic GnuTLS.

(...)
> I am not against adding test cases as early as possible. I’m just against a
> setup where a test for missing features completely block CI, nightly builds
> and does not give visibility for other failing tests.

That is irrelevant:

1) No tests do not block CI unless you make them so.

2) Other tests are failing on MacOS anyway; you just turned off debugging and 
did not enable sanitizations to make them *artificially* pass.

3) All other tests are visible anyway, except for the minor run_vlc.sh.

> > 3) TLS ALPN is not a "new" feature anyway, and it was not a new feature
> > when the test cases for it were added either. As a matter of fat, the VLC
> > API was added in August 2014, while the test cases were added in January
> > 2016.
> I think its not very relevant how new the feature is.

I guess it was another David Fuhrmann that mentioned new feature on IRC then.

> > 4) TLS ALPN is also not a "missing" feature, since all the reference TLS
> > plug- in support it. Whether you like it or not, the GnuTLS plug-in is
> > the only reference implementation of the VLC TLS API. Historically,
> > Gildas insisted on making it a plug-in only to avoid libvlc proper
> > depending on GnuTLS, not really to support alternate implementations
> > (since OpenSSL was hopeless). You cannot expect VLC developers at large
> > to support an alternate implementation that targets a proprietary OS and
> > a closed-source (TLS) back-end, requires expensive and dedicated hardware
> > (oh, at least it is not using a different programming language!).
> > Likewise VLC developers should be expected to take care of the Qt GUI,
> > not the MacOS one.
> 
> Please stop the trolling, it does not belong here.

You are violating the CoC again. I am closing this discussion with prejudices.

-- 
Rémi Denis-Courmont
http://www.remlab.net/