Hi Alberto, Thanks for your feedback!
On 09/14/2016 04:04 PM, Alberto Luaces wrote: > [dropping individual addresses and adding our packaging mailing list] > > Sebastiaan Couwenberg writes: > >> Dear OpenSceneGraph maintainers, >> >> What are your plans for OpenSceneGraph 3.4? Do you intend to have it >> included in stretch alongside OpenSceneGraph 3.2 or instead of or not >> included in stretch at all? >> > > Our original intent was to release both 3.2 (already present in stable) > and 3.4. > >> >> The upcoming osgEarth 2.8 release (whose release candidates are >> available in experimental) has bumped the minimum required OSG version >> to 3.4 which leaves experimental as the only place to upload the >> packages as long as OSG 3.4 is not in unstable. >> > > We did not move 3.4 to unstable because 3.6 was announced to be released > at the end of July, but somehow it has been delayed. We intended to > package 3.6 in stretch. Assuming 3.6 is released before the transition freeze in November you're likely to include it in stretch. As long as 3.6 is released before the soft freeze on January 5th it can still be included in stretch, but a transition to it won't be an option. >> If you intend to include OSG 3.4 instead of 3.2 in stretch, we need to >> investigate compatibility with 3.4 in its reverse dependencies. If not >> we can leave things as they are. > > I am certainly interested on aiding osgEarth to be updgraded to newer > versions. Maybe we can test the current developer (OSG-unstable) > release 3.5.4. The primary reason we have osgEarth in Debian is for the Globe plugin in QGIS, which unfortunately doesn't support osgEarth >= 2.6 in the 2.14 LTR we have in Debian. QGIS 2.16 does support osgEarth 2.7, and possibly supports osgEarth 2.8 too but I haven't tested that yet. So there is no pressure from our side to get OpenSceneGraph 3.4 or later into stretch. I'm perfectly happy to keep osgEarth 2.7 in stretch. QGIS 2.16 is probably the last version to support Qt4, although a 2.18 (non-LTR) release might still happen too, QGIS 3.0 will switch to Qt5 which the OpenSceneGraph and osgEarth packages also have done for 3.4 and 2.8 respectively. Those may be better fit for the eventual QGIS 3.x LTR which we aim to get into stretch-backports. That eventual QGIS 3.x LTR backport could be accompanied by OpenSceneGraph 3.4/3.6 and osgEarth 2.8 backports which will all use Qt5. QGIS and osgEarth are not the only OpenSceneGraph reverse dependencies maintained by the Debian GIS team, we also have SFCGAL, OTB and OSSIM. SFCGAL is not very actively developed, but it's reliance on OSG is limited, we can easily drop the OSG support when it's no longer compatible with the version in Debian. OSSIM & OTB only use libopenthreads, which is currently only provided by the OSG 3.2 packages. We also have other OSSIM packages in progress which do use libopenscenegraph, but these need a lot more work before they're in acceptable shape for inclusion in Debian. As long as the changes to libopenthreads aren't too disruptive in later versions, I don't expect too many issues with those either. So all in all, I'm happy to keep osgEarth 2.8 in experimental along with OpenSceneGraph 3.4/3.6. I'll have to think about moving it to unstable when OSG 3.4/3.6 does, for the eventual Qt5 using QGIS 3.x that's probably a good idea, although it will break the globe plugin for users of the upstream QGIS 2.16 packages. So we may want to stick to OSG 3.2 and osgEarth 2.7 for stretch after all. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
