[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