Bug#659705: libmpeg2-4: Upload 0.5.x to unstable?

[Loïc Minier]

On Mon, Feb 13, 2012, Alessio Treglia wrote:
> I've converted the SVN repo into a new git one, here is the result:
> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpeg2dec.git

 There are in my eyes two ways to deal with importing the history of
 this package:
 a) start from the history in the packaging SVN repo

 pros:
 - fine grained history

 cons:
 - doesn't intermix with upstream history very well
 - mixes "upstream files in working tree" with "just debian/ in working
   tree"
 - no strict relationship to archive contents

 b) start from the Debian upload history (.dsc files as downloaded from
 snapshot.debian.org or from Launchpad, or convert bzr history from
 lp:debian/mpeg2dec)

 pros:
 - matches archive contents
 - consistenly "upstream files in working tree"
 - easy to mix with upstream tarball history

 cons:
 - doesn't mix with upstream git history if any


 Your git repo has partial SVN history, I don't know why; if I svn log
 the unstable mpeg2dec branch in pkg-multimedia it goes down to commits
 of David Lehn in October 2000 and has imports of the CVS history; these
 I don't see in your git repo.

 I would personally think this kind of deep history isn't terribly
 useful because its form is inconsistent (e.g. debian/ alone or not) so
 that you would only be able to git blame certain debian/* files.
 That's why I would personally recommend b), even if that means not
 seeing some of the finer grained history (my commits for instance).

 In any case, we must keep the SVN history somewhere; never wipe the SVN
 repo (you can commit an empty the tree though).

 To create b), I think I would either download the .dscs from Launchpad
 using a script or from snapshot.d.o, and then run git-import-dsc on
 them.


 Another separate question is how to integrate with upstream history;
 you could try mixing it with the Debian history, but you need to ensure
 that the Debian upload tags in the git repo correspond to uploaded
 .dscs.  It's usually trickier to get this right, and it's really useful
 when dealing with a large set of cherry-picked upstream patches
 directly committed in your git repo, not useful when using a patch
 system though.  I would recommend sticking to the branch of imported
 tarballs as the branch mixing history with the Debian one.  You can
 always push some upstream git-ified history to the repo if you like and
 cherry-pick from it or export patches to debian/patches from it.

   Cheers,
-- 
Loïc Minier