Multimedia Teams in Debian

[Felipe Sateler]

El 29/11/08 17:41 Reinhard Tartler escribió:
> 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.

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

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

Saludos,
Felipe Sateler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20081129/6dae45ba/attachment.pgp