Multimedia Teams in Debian

[Felipe Sateler]

El 30/11/08 04:32 Reinhard Tartler escribió:
> 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.

Yes, but that requires me to remember to do that :). The point was that doing 
this requires more effort than it's worth, if upstream does releases 
frequently.

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

Ehm, I'm not sure I understand this. Moving the libswscale repository back to 
ffmpeg would break bisecting of libswscale, you mean? And Diego is trying to 
retrofit libswscale's history into ffmpeg's?

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

For the same reasons you take a particular snapshot any time. It just saves 
you the hassle of manufacturing a tarball and importing it into a "fake" 
upstream branch.

> Would that make it rather 
> difficult for upstream to know what changes we have done in the package?

I worded it badly. The tag would be present in the debian git repository, and 
as such it would be public. Also, upstream doesn't need to care about this, 
since we would still be using quilt patches that can be mailed to them. Also, 
if upstream is tracking the debian branch, merge points are stored, so 
upstream knows precisely which point in time you snapshotted.

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/20081130/c2535f64/attachment.pgp