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

[Rémi Denis-Courmont]

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.

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