<!DOCTYPE html>
<html data-lt-installed="true">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body style="padding-bottom: 1px;">
<p>Hello,</p>
<p>I wanted to wait a while before replying to see if more people
would be involved. Since no one has joined the discussion, I think
it is safe to assume that no one objects to the proposed changes
here.</p>
<p>> I think discussions should happen in an issue (Feature
Request) as doing it here will probably have less visibility, but
we'll see.</p>
<p>Since this is not an "issue", I'm not sure what is the best to do
regarding these. GitLab does not allow me to classify as "task".
In the past, I opened a few of these marked as "incident", but I
nowadays think the development mailing list is better suited for
non-issues. Everyone can participate here, but I'm aware that some
people can't/don't use GitLab.</p>
<p>> There's only one way to settle this: actual numbers for the
time it takes to start between the two.</p>
<p>I was told that performance is the top priority, so numbers
should not matter as long as switching does not bring additional
problems.</p>
<p>> IMO we should have zstd. My understanding is that it's much
faster to compress/decompress but it doesn't compress very well.
For this particular use case it seems to better candidate.</p>
<p>Are we willing to build zstd twice (for cross platform case)?
And, if zlib is used by multiple contribs and zstd only by Qt,
then we still would like to make zlib faster. But that does not
mean that we should not use zstd, at least that can be used by Qt
for the moment.</p>
<p>> The license is pretty clear, it's BSD</p>
<p>If I remember correctly, the problem was re-licensing without
consent. I'm not sure if it is okay to _knowingly_ use such
programs. Of course, it is hard to ensure if all contribs adhere
to their licenses, but if it is _clear_ that a program violates
its license, then it may be bad faith to use it / continue using
it.</p>
<p>For reference, this was the thread noticing this:
<a class="moz-txt-link-freetext" href="https://code.videolan.org/videolan/vlc/-/merge_requests/4791#note_423073">https://code.videolan.org/videolan/vlc/-/merge_requests/4791#note_423073</a>.</p>
<p>> I'm not sure how more reliable it is to the official zlib.</p>
<p>It seems to be well established at this point, after 10 years of
its introduction and considering its popularity. But, the Chromium
fork may be better for reliability, for obvious reasons. If I had
to choose myself, I would go with zlib-ng.</p>
<p>> We do but I'm not sure C/C++ contribs should depend on a
rust contrib. At least not a hard dependency.</p>
<p>OK, let's put zlib-rs off the table. It seems there are two
viable alternatives if we want to switch, the Chromium fork, and
zlib-ng.</p>
<p><br>
</p>
</body>
<lt-container></lt-container>
</html>