Multimedia Teams in Debian

[Reinhard Tartler]

Felipe Sateler <fsateler at gmail.com> writes:

> There's also git-cvsimport, which I used for a while. However, the import 
> stage is very slow, since it is done over the net. Subsequent updates are 
> very slow too (unless one keeps the cvsimport updated very frequently). The 
> problem is that one has to checkout every point in history, making it very 
> slow for relatively large projects.

in order to speed up the whole thing, I'd recommend rsync'ing the cvs
repository to localhost first and then run the conversion. That's how we
tracked the OpenBSD CVS in git in a project I've worked previously on.

>> > In the case of ffmpeg, where there are no released tarballs, it would
>> > make sense to directly track the git repository (ie, the upstream
>> > branch is a clone of upstream's master branch).
>>
>> The particular problem with ffmpeg is that upstream uses svn externals
>> to track the 'libswscale' subdirectory. The upstream git repository even
>> leaves that directory out completely. I haven't found a better way to
>> track upstream than what we currently have as the current
>> get-orig-tar.sh, but I'm open for improvements on that.
>
> Hmm, this is strange. I assume libswscale can't easily be built independently 
> of ffmpeg, or that would be done, am I right? What motivation has upstream 
> for doing this?

libswscale is historically developed in the mplayer svn, ffmpeg has more
or less integrated that in their own tree (well, it is optional but has
more features than the internal scaler). It has no standalone
buildsystem, but integrates cleanly in both the ffmpeg and mplayer build
system.

The sanest way would be to move the libswscale repository back to
ffmpeg. That however would break bisecting, so they insist on rewriting
the ffmpeg svn repository so seamlessly integrate the development
history. This is a tedious job Diego is working for over a year on.

>> > In either case, "upstream" releases should be tagged (eg,
>> > upstream/x.y.z~svn123 as git-buildpackage tags them). The debian diff
>> > is not a diff against upstream's tip, but against these tags.
>>
>> If we track "upstream releases" (which I think we should do by default
>> unless there are compelling reasons not to do so, see the ffmpeg
>> example), indeed!
>
> Note that upstream releases need not be official. You can tag in your local 
> copy some point in history as upstream/x.y.z+somedate, and use that as the 
> upstream release.

Ugh. And why and when should we do that? Would that make it rather
difficult for upstream to know what changes we have done in the package?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4