[vlc-devel] [vlc-commits] include: work around LLVM brain damage

[Rémi Denis-Courmont]

Le maanantaina 27. helmikuuta 2017, 22.20.00 EET Marvin Scholz a écrit :
> > Oh the hypocrisy. Oh the ingratitude. That  change is a trivial
> > stopgap to
> > make the build logs readable for people like you using LLVM.
> 
> I never said that I consider this patch wrong, I was just pointing out
> that it would have been more friendly,

Look, either the patch was merged or it was not. If it was not, then LLVM 
users (including you) cannot read the build logs. I don´t think waiting for an 
agreement (which might not come any time soon) is practical. And the potential 
merge conflict from a one-liner is trivial to fix.

> in regard to the ongoing discussion
> about
> the
> topic, to send it to the ML and maybe point out that you only intend it
> as
> a temporary solution until a better one is found.

Oh come on. The patch description started with "work around".

> Whenever someone breaks the build you complain and nearly immediately
> revert, or even force- push the changes away. It is not like people break
> the build just to annoy you, you know?

If the code does ostensibly not pass the test suite on any target, then it is 
fair game for revert. This applies to my code too. And my code is the code 
that I most frequently force push and/or revert.

> On top of that, you break the build frequently too.

And what do you expect? That I complain to my own self on the mailing list? 
When I break the build, either I notice quickly and rectify, or I don´t know 
and somebody else fixes/reverts it.

Also, there is no such thing as a "the build". I held my last "major" build 
system change (skins2 derecursion) from push for two weeks because I did not 
have access to proper computer to validate it... And yes, the initial version 
did turn out to break the build.

Not that you´d notice unless you compare the commit and push timestamps.

> In the last case I remember, even knowingly with your tls module
> changes.

So I broke a platform-specific important but non-essential plugin for a 
proprietary library and with an obvious fix on a single platform. JB and your 
changes rendered VLC not debuggable on any platform and with no obvious fixes 
other than revert. That´s really not the same level.

Besides, the TLS module exists only because Gildas did not want to link LibVLC 
(nowadays libvlccore) to GnuTLS directly. The goal was _never_ to allow 
alternative backends. And indeed, to this day, there exists no other proper 
alternative since the ST plugin does not fully implement the API.

I think I did warn that adding another backend would cause problems if I 
cannot test it. Indeed, many honest attempts to update it failed. Thing is, 
AFAIR, David and Felix took responsibility for following up when ST was 
merged. I would never agree to merge ST if I´d had to maintain it myself.

This will continue until/unless somebody documents a reasonable way to 
validate changes offline on an OSS development environement.

And that you were not part of the project at the time when ST was merged is 
not an excuse for lashing out at people. I have never committed to whatever 
you want the TLS change policy to be, and I won´t for the foreseeable future.

> Even though it only affected macOS, it was annoying and unnecessary.

First, this is self-inflicted pain for using a platform-specific plugin. And 
second, the change was necessary.

> You could have sent the patches to the ML and asked one of the macOS devs to
> fix the ST module to work with your changes, in case you do not want/can't
> easily do the necessary changes yourself.

Sending patches to the ML does not magically spawn patches. And even if it 
did, it wouldn´t avoid incremental build breaks.

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/