Multimedia Teams in Debian

[Free Ekanayaka]

Hi Felipe,

|--==> On Sat, 22 Nov 2008 15:15:16 -0300, Felipe Sateler <fsateler at gmail.com> said:

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

  FS> In our case, we track upstream releases only, but only because it doesn't make 
  FS> much sense to do otherwise[1]: csound uses CVS (ugh), thus making it painful 
  FS> to track it directly. In the case of ffmpeg, where there are no released 
  FS> tarballs, it would make sense to directly track the git repository (ie, the 
  FS> upstream branch is a clone of upstream's master branch). In either 
  FS> case, "upstream" releases should be tagged (eg, upstream/x.y.z~svn123 as 
  FS> git-buildpackage tags them). The debian diff is not a diff against upstream's 
  FS> tip, but against these tags.

That is the same approach I adopted, and the default one of
git-buildpackage, I think it makes sense to stick to it.

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

Well, but is not in the pool and the binary gets build against the
stripped version, I think we can live with this.

  FS> The ffmpeg case is somewhat particular, as the same packaging can build 2 
  FS> source packages (ffmpeg and ffmpeg-debian). I'm not really sure what approach 
  FS> 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.

I also would stick to quilt patches, to be included in the debian
source package. However I would also keep a long-lived branch for each
of them, because it might be useful to track the history of a patch,
or split it into individual commits.

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

  FS> 1. Packages should be maintained in a git repository (using the pkg-multimedia 
  FS> or demudi namespace?)

demudi has already a repo on git.debian.org, and I prefer it over
collab-maint because the latter is writable only by DDs (for non-DDs
you have to ask for write permission on case-by-case basis), while the
former is writable by all the members of the relevant Alioth project,
DDs or not.

While we are at it we might want to change the name to something
different at all, creating a new project called "debian-multimedia"

I am the one who created the demudi alioth project, and AFAIR at that
time it was not possible to name it "debian-multimedia" because the
name was to long, so I went for demudi. Things might be changed now,
or we can ask for an exception.

  FS> 2. The maintainer field should be set to...

Personally I don't care too much about the name, as long as bug
reports and upload notifications are forwarded to the same list as the
team's discussion list. At least initially.

  FS> 3. Patches to upstream should be stored as quilt patches which are then used 
  FS> in the build process (ie, no direct changes to the source files).

I would like to have a git branch for these patches as well, but we
might want to make this optional. For very small patches it is
probably overkill.

  FS> 4. How to manage upstream sources?

As said, I would stick to the git-buildpackage standards, that means a
git branch for upstream sources, which can get imported with

git-import-orig

Ciao!

Free