[vlc-devel] [PATCH] patches applied to VLC

[Rémi Denis-Courmont]

	Hello,

Le mardi 15 novembre 2011 21:26:07 Ross Finlayson, vous avez écrit :
> I'm not sure how much of this rant was intended for me, and how much was
> intended for the "vlc-devel" mailing list.
> 
> The real problem here is that you are 'patching' the LIVE555 code at all. 

The real problem is that you refuse to provide a read-only source control 
system for people to patch the latest version of your software, thus deterring 
any contribution.

In that respect, you conveniently ignored one of Rafaël's question in that 
respect, just like you did 2,5 years ago another time those patches came up:
http://mailman.videolan.org/pipermail/vlc-devel/2009-March/057863.html

> The code - as I distribute it - works just fine for almost everyone,

We came up with the uselocale() patch, because live555 was crashing on MacOS. 
So much for working fine. You rejected the patch:
http://mailman.videolan.org/pipermail/vlc-devel/2008-July/046475.html

> as far as I can tell, and is not intended to be 'patched' it at all before
> being usable.  Most people should be able to use the LIVE555 code in VLC
> 'as is', I think.

You cannot reject our fixes on the one hand, and tell us to not patch on the 
other hand. VLC needs live555 to work, reliably, on modern Linux and on 
current MacOS.

> Note, for example, patch 1, about "inet_ntoa()" not being thread safe. 
> While that's true, it's not important for LIVE555 and VLC

No.

> because

> (1) we use our own version of this function, with our own name, and

That only helps on VxWorks (which VLC does not run on by the way). On other 
operating systems, inet_ntoa() is being used either way.

> (2) LIVE555 code is not accessed by more than one thread in VLC at all

Nothing warrants that. With VLM or with LibVLC, you can spawn more than one 
input in a single process.

> (at least, it shouldn't be).

If you do not want live555 to not be re-entrant, then you have to expect that 
we will patch it. That is the whole point of open-source. We adapt your code 
to our needs, which include thread-safety and reentrancy.

It is up to you whether you, as upstream, want to cooperate. It is not up to 
you whether VLC creates multiple RTSP input per process.

> Similarly, I'm not convinced yet about the need for patches 2 and 3.

Exact same thing as patch 1.

> Patches 4 and 5 look more plausible, but this is the first that I had
> heard about them (read the next two paragraphs).

Unfortunately, that is quite possible. We gave up on notifying you given the 
results with earlier patching highlighted above.

> But if you really feel that you need to modify the code to get it to work
> for VLC, then why did you never tell me about this before (e.g., using our
> "live555-devel" mailing list)???

You are trying to rewrite history here. Or was this not you?

http://mailman.videolan.org/pipermail/vlc-devel/2008-July/046475.html
http://mailman.videolan.org/pipermail/vlc-devel/2009-March/057830.html
http://mailman.videolan.org/pipermail/vlc-devel/2009-March/057862.html

> If you ask me nicely, and your request
> is reasonable, then I'll gladly update the released code accordingly. 
> That would be the best solution for everyone.
> 
> VLC is a great system, and I love it, and I recommend it to everyone, and I
> respect its developers - but it's not the center of the universe, and it's
> far from the only application out there that uses the LIVE555 libraries.

Nobody claimed that VLC was the only user of live555, let alone the center of 
the universe. I do claim our patches are needed to get live555 to work within 
VLC. And furthermore, I do claim that they does not alter the external 
interface or the functionality of live555, and some of the addressed issues do 
affect other applications.

> If you think the LIVE555 code needs to be changed to work better, then
> surely you'll agree that it'd be better (nicer) if you let these other
> applications get the benefit of these changes, rather than keeping them
> exclusive to VLC.

Exactly. That is why, in the face of an uncooperative upstream, we push our 
patches downstream. As an example, Debian took (some of) our patches already 
for a long while, where all applicatiosn on Debian and Debian-derived 
distributions benefit from them.

> So, what would you like me to do now?

We would rather you fix live555, with our patches or with others.

> Should I review these 'patches', and make appropriate modifications to the
> released LIVE555 source code (not necessarily identical to these 'patches',
> but probably close)?

If you want us to stop patching, then yes.

> If I do this, do you then promise, in the future, to let me know if you feel
> that the code needs to be modifed again before being used by VLC (so
> that other applications can also get the benefits of these modifications)?

I will not promise anything so long as live555 has no readable VCS.

Regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis