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"
* 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
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
to keep the development and the packaging separately. If you
to maintain a fork of the primesense/sensor repo, we could base
package off of that for now.
it's something we have added. Should we put it on github and
with the avin2 branch?
That works for me.
Here it is: https://github.com/ros-pkg-git/Sensor/tree/master.
based on the avin2 branch (as they are not really based to the
OpenNI once), let me know if you that's ok for you. By the way,
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
That's why this repo is not a fork of the upstream repo.
According to the git-buildpackage documentation  the upstream-
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
for you, I'm fine with it.
So if we decide to make primesense-kinect-sensor based off of your
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
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  where we use the
of my version. As there is a ITP  for it, it would be nice if the
package would include it, so the OpenNI part of PCL would work as
once it's packages.
Regarding the base for the package I'm fine with the avin2 fork, as
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.
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 ?
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