Multimedia Teams in Debian

[Felipe Sateler]

El 22/11/08 05:47 Reinhard Tartler escribió:
> Felipe Sateler <fsateler at gmail.com> writes:
> > I think it avoids confusion to have a single list. If later on it shows
> > to be a problem, the list can be split. Maintaining both lists from the
> > start sounds like preemptive optimization to me.
>
> Ok, with that having in mind, I'm OK with using a common list. In case
> "problems arise", we reconsider. OK.
>
> >> I've made these drawings before vcs-pkg.org was founded. After that,
> >> Marting and the other guys over there did come to similar conclusions
> >> but even further reaching conclusions. I at least try to follow their
> >> discussion mailing lists.
> >
> > I haven't been following lately, but it appears the current "panacea" is
> > TopGit... haven't tried it yet though. I'll give it a spin.
>
> AFAIUI TopGit is a tool on top of git that can convert quilt patches to
> git branches and vice versa. See below.

Eehm, AIUI, TopGit works from branches to quilt. Not the other way around.

>
> >> > Agreed. Uniformity is key for collaboration across packages.
> >>
> >> Ok. What mode do you propose?
> >
> > I don't think it's important what particular mode is used, as long as
> > it's consistent.  What I do for csound is an upstream branch tracking
> > releases, and a master branch where we use quilt for patch
> > management. I think it makes it easier since most patches are
> > short-lived in our case.
>
> Key facts here:
>
>  - upstream branch *tracking* upstream
>  - patch management using quilt.
>
> 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. 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). 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.

>
> FWIW, I think that is a very reasonable approach. For ffmpeg, I have
> written a get-orig.source.sh shell script that can generate arbitrary
> "releases" with any mangling debian packaging requires. I think that
> approach can be adopted by other packages, even if they don't need
> special mangling. In the simplest case, the get-orig-source.sh script
> will be a frontend to uscan(1). In any case, the result of that script
> is then used as base for commits in the "upstream branch", see above.

It's a simple approach, so it would probably minimize confusion. Another way 
we used to do with csound is: the upstream branch contains the pristine 
upstream tarball, the dfsg-clean branch has the mangled upstream code and the 
master branch contains the debian packaging. Then builds are done against the 
dfsg-clean branch instead of the upstream branch, and unstripped builds can 
be done agains the upstream branch. The problem with this approach is that 
the code that you are stripping because you can't/don't want to distribute in 
Debian is still served by Debian via the vcs in alioth.

The ffmpeg case is somewhat particular, as the same packaging can build 2 
source packages (ffmpeg and ffmpeg-debian). I'm not really sure what approach 
is the best. I would 

>
> >  Other people prefer topic branches and an integration branch. This
> > may be better for longer-lived patches.  The guys from vcs-pkg seem to
> > swear by this last workflow. TopGit seems to be able to generate a
> > linear quilt patchset, which is nice for people wanting to review the
> > source package.
>
> Exactly. I think we don't do a mistake if we continue maintaining quilt
> patches for now. I'd say let's see how this works out and reconsider
> later.

Lets try to set a few guidelines for new/transitioning packages, then. 

1. Packages should be maintained in a git repository (using the pkg-multimedia 
or demudi namespace?)
2. The maintainer field should be set to...
3. Patches to upstream should be stored as quilt patches which are then used 
in the build process (ie, no direct changes to the source files).
4. How to manage upstream sources?

[1] At least, that's what I thought when I first created the git repo. I don't 
know if my comaintainer agrees on the motivation.

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/20081122/05e1fc62/attachment.pgp