Multimedia Teams in Debian

[Reinhard Tartler]

Felipe Sateler <fsateler at gmail.com> writes:

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

it would break bisecting ffmpeg with having libswscale enabled.

>  And Diego is trying to retrofit libswscale's history into ffmpeg's?

yes.

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

I cannot imagine any case when I would have wanted to do that. could you
perhaps name examples? Maybe I just don't understand this point, but it
doesn't seem too important to me either.

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

upstream would still have the hassle to understand git and the way we
use git. I'd prefer to save them this efford unless we have good reasons
to do so.

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