On Jun 19, 2011, at 3:05 AM, Jochen Sprickerhof wrote:

* 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:

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.

[1] /usr/share/doc/git-buildpackage/manual-html/ gbp.intro.html#GBP.REPOSITORY
[2] http://pointclouds.org
[3] http://bugs.debian.org/624178

Sounds to me like you are much deeper in this code than I am, so I would defer to you on that topic :) I'm mostly am thinking of the long term policy for this package, and what makes sense for the code that's out there. So I don't have strong opinions on how it shaped for the most part. My guess is that the package should try to stick to the primesense code as much as possible, as long as they are accepting patches so that their codebase is usable for Debian. So yes, all changes as patches in debian/patches makes sense to me.

I've mostly achieved my goal, which was making it really easy to use skeleton tracking with other media software, but I'm happy to stay involved as much as I am useful. I'm about to have a baby, so I'll probably be not around for a while, so don't worry about waiting on me to get stuff done.

Speaking of it, did you see the Fedora patches
over there [4]?
[4] https://github.com/OpenNI/OpenNI/pull/10]

That looks very useful, I hope they accept it.



"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White

pkg-multimedia-maintainers mailing list

Reply via email to