[vlc-devel] [vlc-commits] commit: contrib: Fixed SVN version number for contribs. (Pierre d' Herbemont )

Rémi Denis-Courmont remi at remlab.net
Thu Nov 18 11:23:37 CET 2010


On Thu, 18 Nov 2010 09:40:36 +0100, "Pierre d'Herbemont"
<pdherbemont at free.fr> wrote:
> It's certainly a good start. And as the release manager it's up to you.
> But fixing now and then external dependencies, even during development
> cycles is a waste of time.

Nobody forces you to rebuild your contrib.
Nobody forces you to use a broken system that needs and breaks contrib
either.

(...)
> Now the reason I do that, is that, what if we want to re-create the very
> same contrib snapshot from a given revision number? We can't. It's a pity
> not to be sure that the regression is not in the contrib from two
> snapshots.

There is no way to recreate an exact same binary anyway.
If you want the exact build, keep the exact same build around.

> What also about GPL there?

That's totally irrelevant. You would be collecting the source tarballs at
the same time you make the binary anyway.

> Since we are redistributing nighlties, we have
> to re-distribute the exact sources, and at least point at what version
> we've embed in.

That's not even necessary. You can publish your binaries under GPLv3 for
_no_ profit. Then you can point people to the upstream source
repository/website instead of giving them the source code.

> No, seriously, I think this has to be done. What concern do you have? If
> the idea is to be able to simply update to latest SVN revision, we could
> do a script for that. Is that it?

No. We don't want every second commit in vlc.git to read "bump FFmpeg SVN
version".
At least not as long as contribs are part of vlc.git

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




More information about the vlc-devel mailing list