mplayer branches explanation?

[Reinhard Tartler]

A Mennucc <debdev at tonelli.sns.it> writes:

> hi Reinhard

Hi,

I see that you've written this email yesterday, but I noticed them only
right now. Sorry for the delayed answer.

> I see there are a lot of branches in our mplayer GIT
>
> may please explain their intended usage?
> (just to be sure, so that we all can interact with those understanding
> the semantic)

Sure, here we go:

first, the easy ones

>   origin/upstream

This branch contains the *contents* of the orig.tar.gz as it should go
to debian. If we would package mplayer releases, it would match the
release tarball, minus the modifications we need to do in order to make
it acceptable for ftp-master.

>   origin/upstream.unstripped

This branch contains the *contents* of the orig.tar.gz without
modifications that remove functionality.

>   origin/pristine-tar

This is a control branch for use with pristine-tar(1), see the package
with the same name. It is a tool to exactly recreate the
.orig.tar.gz. In principle it works as follows: First, it exports the
contents of the 'upstream' branch in a temporary directory and creates a
tarball out of this. Then it uses xdelta to apply the binary patch so
that the tarball is bit-identical to the tarball that was checked in.

I find it very useful for 2 reasons:

 - if the orig.tar.gz is already in the archive, I don't need to look it
   up from the mirror or even worse, snapshot.debian.net.

 - if the orig.tar.gz is not yet published, I don't need to place it
   somewhere in public for fellow team members so that they can test the
   package.

You can think of pristine-tar as helper tool that aids with
synchronisation of the .orig.tar.gz

In order to use it it seem you need to create a 'local' pristine-tar
branch like this:

 $ git checkout -b pristine-tar pristine-tar

To update that branch:

 $ git checkout pristine-tar && git pull

> * master

That is your local copy of the branch 'master', most likely it matches
origin/master.

>   origin/HEAD

AFAIUI it is a pointer to the head of master.

>   origin/master

This branch contains the contents of the source package as it should go
to 'unstable'. If we decide to start parallel development, e.g. on a
package that go to experimental or to lenny, we'd start a new branch
'experimental' or 'lenny'.

>   origin/master.unstripped

This is the 'twin' branch of master. It mirrors the 'master' branch, but
contains all bits that have been pruned for not being acceptable in
debian. In principle the diff between master and master.unstripped
should be the exact diff of what ftp-master is not going to accept in
debian.

In practise master.unstripped is currently a bit behind of master for
workflow reasons. Currently, we work only in 'master' to get the package
ready for debian. At the point where we are ready to upload (and
eventually even upload it to debian), we then merge the changes from
'master' to 'master.unstripped'. The first merge will need some care,
because it will most likely remove some bits that we actually want to
have. I'll take care of that, don't worry.

If 'master' has been uploaded, we can continue to work on
'master.unstripped'. That branch can indeed package even mencoder, as it
is not intended for inclusion into debian. We can consider publishing
that package "somewhere". The point here is that we do any changes we
want to 'master.unstripped' without needing to worry about 'master' too
much.

At some point, we are ready with 'master.unstripped' and a mencoder
enabled package is published (or not, doesn't matter). Then we can
'git-diff' the branches and see what modifications are okay for the
'master' branch, which we then commit.

You see this is a back and forth of merges between 'master' and
'master.unstripped'. This may seem complicated, but in practise you can
focus on getting the package ready that you work on. Before, the same
packaging had to be tested for both variants at the same time (the
non-DFSG variant and the debian variant). I think this is a big
improvement maintenance wise.

One drawback that I see is that upstream upgrades to a new svn snapshot
are (a bit) more difficult. I've sketched the procedure copy-and-paste
ready in debian/README.upstream-upgrade. Please also see the copy of
this file in the ffmpeg branch.

This whole approach is not new, I've implemented it exactly like this
for ffmpeg, where it works very will, IMO. I know that it is totally
different to the approach you've implemented before in the mplayer
package, but please forgive me that step (and my immodesty), I really
think that the approach outlined in this mail is superior.


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