Multimedia Teams in Debian

[Reinhard Tartler]

Felipe Sateler <fsateler at gmail.com> writes:

>> For point 1: How often do you "snapshot" upstream? Every upstream commit
>> of their VCS or only upstream releases? What to do with upstreams that
>> don't do commits in years? (think ffmpeg, toolame).
>
> In our case, we track upstream releases only, but only because it doesn't make 
> much sense to do otherwise[1]: csound uses CVS (ugh), thus making it painful 
> to track it directly.

for cvs, there is cvs2svn, which can export in a format compatible to
git-fast-import. Therefore AFAIUI it should be pretty easy to track the
upstrem cvs with git.

I'm not suggesting (yet) to do that. I think it only makes sense if we
had a large set of patches that we want to get upstream. 

> 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.

> 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!

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