Re: OpenNi in Debian
On Jun 19, 2011, at 3:05 AM, Jochen Sprickerhof wrote: * Hans-Christoph Steiner [2011-06-19 00:07]: On Wed, 08 Jun 2011 03:07 +0200, "Jochen Sprickerhof" wrote: * Hans-Christoph Steiner [2011-06-07 18:47]: On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote: * Hans-Christoph Steiner [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. [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. .hc "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 pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: OpenNi in Debian
On Jun 19, 2011, at 4:00 AM, Reinhard Tartler wrote: On Sun, Jun 19, 2011 at 09:05:46 (CEST), Jochen Sprickerhof wrote: 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. That's the price of the overhead of team work. As a team, we want to use the same workflow on all packages. Since not all upstreams maintain the sources in git, we need to come down to the lowest common denominator, which boils down to importing tarballs. The other side of it is that the upstream git repos are a mess. The PrimeSense repo is not used for development, and has a quite unusual structure. It looks like to me they are just importing releases and not doing any development out of that git, plus they are using the two branches as separate repos, one called 'master' which is the stable releases, and the other called 'unstable'. As code is pushed to the stable releases, it is not merged from the 'unstable' branch into master. Then it looks like the avin2 fork is a new reconstruction of the git repo to be more git-like, but then that doesn't follow the original git. But I think if I was avin2, I'd do the same. .hc "Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: OpenNi in Debian
On Sun, Jun 19, 2011 at 09:05:46 (CEST), Jochen Sprickerhof wrote: > 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. That's the price of the overhead of team work. As a team, we want to use the same workflow on all packages. Since not all upstreams maintain the sources in git, we need to come down to the lowest common denominator, which boils down to importing tarballs. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: OpenNi in Debian
* Hans-Christoph Steiner [2011-06-19 00:07]: > > On Wed, 08 Jun 2011 03:07 +0200, "Jochen Sprickerhof" > wrote: > > * Hans-Christoph Steiner [2011-06-07 18:47]: > > > > > > On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote: > > > > > > >* Hans-Christoph Steiner [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 Cheers, Jochen [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 pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: OpenNi in Debian
On Wed, 08 Jun 2011 03:07 +0200, "Jochen Sprickerhof" wrote: > * Hans-Christoph Steiner [2011-06-07 18:47]: > > > > On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote: > > > > >* Hans-Christoph Steiner [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. 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. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
