[vlc-devel] [PATCH] contrib: gnutls: fix win32/winstore patches

Rémi Denis-Courmont remi at remlab.net
Tue May 19 16:54:29 CEST 2020

Le tiistaina 19. toukokuuta 2020, 8.16.06 EEST Steve Lhomme a écrit :
> On 2020-05-18 17:26, Rémi Denis-Courmont wrote:
> > Le maanantaina 18. toukokuuta 2020, 18.11.44 EEST Rémi Denis-Courmont a
> > écrit> 
> >> Hi,
> >> 
> >> I don't think it's appropriate to push such a huge patchset. It's pretty
> >> much impossible for anybody, except maybe you, to upgrade with this (or
> >> then it will break Windows).
> > 
> > In other words, contribs is not the place to maintain large patchsets or
> > forks. Patches should be submitted upstream and backports should have the
> > cherry-pick cross-reference.
> I agree and I'm working on getting things pushed upstream. But there are
> many problems. Sometimes people just don't care or don't know their code
> enough or have unmaintained code (a month later I'm still waiting for a
> single answer for this patch
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544191.html).

VLC devs are even less likely to know how to maintain those patches. What do 
we do when there are two separate sets of platform-specific patches and nobody 
knows how to update them both? This can only end two ways: contribs breaks on 
Windows, or the version in contribs is too low and breaks on all platforms 
(which is even worse).

Not only that, but "patches of patches" are just horrible to handle anyway, 
even if you do know the code. It's easy once, and then it's miserable every 
other time.

You can't have it both ways. You can't be complaining that patches don't apply 
on new versions (happened before) and complain that people don't update 
contribs (ditto). And it's not just GnuTLS. There's a been a massive and 
unacceptable increase in contrib patches lately. Only two of them have the 
cherry-pick marking...

It will not end well. Don't come to me for sympathy when Windows break. The 
whole point of the "new" contribs was not to be tied to Windows.

> That doesn't mean we don't want to support it and if we do, we have to 
> do what it takes to get there, even if the original project doesn't. 

That's your opinion. If upstream is missing in action or too stupid to merge 
good code, you should fork or use another project. And if your code is not 
good enough for upstream, then it's probably not good enough for contribs.

> That's why we have so many patches in contribs, sometimes for dead 
> projects. We still review our code, including patches to contribs.

Except when we don't. You're making life impossible for non-Windows devs.

> As for gnutls, it's a sensitive part that needs special care. I will 
> submit what I can upstream, without much hope. But some of the patched 
> code is not even in their repository. It's only in their packaged
> sources. It's probably comes from somewhere else but I don't know where yet.

GnuTLS has automatically generated files (as does VLC and any autotools-based 
project), which of course can't be patched directly, and git-submodules. 
Nothing very special.


More information about the vlc-devel mailing list