* Hans-Christoph Steiner <h...@eds.org> [2011-06-19 00:07]:
> On Wed, 08 Jun 2011 03:07 +0200, "Jochen Sprickerhof"
> <joc...@sprickerhof.de> wrote:
> > * Hans-Christoph Steiner <h...@eds.org> [2011-06-07 18:47]:
> > > 
> > > On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote:
> > > 
> > > >* Hans-Christoph Steiner <h...@eds.org> [2011-06-06 13:05]:
> > > >>
> > > >>I have not been in contact with avin.  Is Bayer images support
> > > >>something that is in the original from PrimeSense, or something that
> > > >>you want added?  If the idea is to maintain new features in the
> > > >>package, I think that should probably be done in a separate git repo
> > > >>to keep the development and the packaging separately.  If you want
> > > >>to maintain a fork of the primesense/sensor repo, we could base the
> > > >>package off of that for now.
> > > >
> > > >it's something we have added. Should we put it on github and merge it
> > > >with the avin2 branch?
> > > 
> > > 
> > > That works for me.
> > 
> > Here it is: https://github.com/ros-pkg-git/Sensor/tree/master. It's not
> > based on the avin2 branch (as they are not really based to the official
> > OpenNI once), let me know if you that's ok for you. By the way, why is
> > the Debian git not connected to the github one? I mean this one:
> > http://anonscm.debian.org/gitweb/?p=pkg-multimedia/primesense-kinect-sensor.git
> These packages are packaged using standard Debian git-buildpackage
> style.  That means that the upstream code is imported from release
> tarballs, and the git master branch is all about the debian packaging. 
> That's why this repo is not a fork of the upstream repo.

According to the git-buildpackage documentation [1] the upstream-branch
can either be imported or a branch you can pull from. So generating
tarballs from a git and then importing them into git again seems to be
superfluous and makes the upstream branch hard to track. But if it works
for you, I'm fine with it.

> So if we decide to make primesense-kinect-sensor based off of your git
> fork, then a release tarball would need to be imported using
> git-import-orig. I'm thinking perhaps its a better idea if you make a
> separate package of your fork.  I used the avin2 fork rather than the
> offical repo for this package because it seems that the official sources
> don't fully work.  It should be really easy to create a ros package
> since the code is so close.  It could be something like
> primesense-kinect-sensor-ros or whatever. 

This has nothing to do with ROS (apart from that it's living in their
repository. I'm one of the authors of PCL [2] where we use the features
of my version. As there is a ITP [3] for it, it would be nice if the
package would include it, so the OpenNI part of PCL would work as well,
once it's packages.
Regarding the base for the package I'm fine with the avin2 fork, as long
as we can put the Bayer patches from my branch inside debian/patches,
but for me it would almost make more sense to base it of the OpenNI
branch (as this is the official version) and put the avin2 patches in
debian/patches as well. Speaking of it, did you see the Fedora patches
over there [4]?

> .hc



[1] /usr/share/doc/git-buildpackage/manual-html/gbp.intro.html#GBP.REPOSITORY
[2] http://pointclouds.org
[3] http://bugs.debian.org/624178
[4] https://github.com/OpenNI/OpenNI/pull/10

pkg-multimedia-maintainers mailing list

Reply via email to