[vlc-devel] Base for VLC ports (was Re: bluray: Add support for overlay)

Rafaël Carré funman at videolan.org
Thu Mar 8 19:43:51 CET 2012


Le 2012-03-08 13:34, Rémi Denis-Courmont a écrit :
> Le jeudi 8 mars 2012 19:43:39 Jean-Baptiste Kempf, vous avez écrit :
>> On Thu, Mar 08, 2012 at 12:39:51PM -0500, Rafaël Carré wrote :
>>> Looks much simpler to me and avoid out-of-sync vlc for android and vlc
>>> repo like you noticed a few days earlier.
>>
>> Probably right on this point, so far.
>> But what happens when we have major core breakage on vlc.git, like when
>> we have an audio core rework or an input/clock rework?
> 
> Of course, there are pros and cons to using master or a stable release/branch 
> as base for new work. On the one hand, you can test the new features and write 
> patches that can be merged upstream. On the other hand, you get bugs and code 
> churn. Live with it like everybody else.
> 
> For the sake of the discussion, lets imagine you target VLC 2.0 for your new 
> work, you finish it and you are exceptionally permitted to apply all patches 
> to vlc-2.0.git. Three months later VLC 2.1 is out. Now what? Well, you are 
> totally screwed because you did not target master. This is true for new ports, 
> but also for new plugins, and even more so for large reworks.
> 
> 
> The good news is that Git is a powerful tool: rebasing patches has never been 
> easier. The bad news is that easier does not necessarily mean easy. So you can 
> stay on some mostly working version; nobody forces you to pull/rebase every 
> day. Then you can avoid most of the churn until you are happy, then rebase 
> once and update the code only once.
> 
> Also with Git, you can fork VLC 2.0 and live happy with a stable underlying 
> API and build system until the day when 2.1 freezes, 2.0 becomes unmaintained 
> and you get to throw all your nice work.
> 
> 
> Personally, I do not care if Android uses VLC 2.0 or master as a base. But if 
> it targets 2.0, it will most certainly not be mergeable: Clean patches would 
> probably be too disruptive for a stable branch, and ugly patches would be, 
> well, too ugly.

It's not really the point because so far there is only one patch for VLC
(for pthread_cancel)



More information about the vlc-devel mailing list