On Mon, Sep 11, 2017 at 2:06 PM, Bas Couwenberg <[email protected]> wrote:
> On September 11, 2017 11:27:38 AM GMT+02:00, Rashad Kanavath < > [email protected]> wrote: > >Hello Bas, > > > >I had pushed a fix to ossim on issue #114 to build ossim apps and ossim > >libs together. (you already knew) > >The License issue #113 cannot be fixed by OTB team. It is the sole > >responsibility of OSSIM. > >The last remaining issue of jsoncpp #115 is another interesting one to > >deal > >with. > >Because it is an amalgamated source of jsoncpp[1] with some changes for > >and > >by OSSIM[2] > > > >[1] https://github.com/ossimlabs/ossim/blob/dev/src/base/jsoncpp.cpp#L1 > >[2] https://github.com/ossimlabs/ossim/commits/dev/src/base/jsoncpp.cpp > > > >I had discussed this issue in depth with OTB developer team during our > >last > >meet. And it is not the first time OTB is fixing errors for this > >project. > >Note that, we have a copy of ossim_plugins which cannot be merged for a > >long time. The problem here is we cannot keep fixing stuff for OSSIM as > >they keep all discussions and releases, private bug tracker far away > >from > >us. > >If the project has cared a bit more about its existence in open source > >ecosystem, it would have been bit more interesting to us. > >Before the last release, we came to know for new releases from OSSIM by > >looking in download.osgeo.org/ossim/ > >And that's just about tip of issues we had with how development > >activities > >goes in OSSIM. > > > >So We had couple of options we like to try: > >1. Keep fixing all ossim bugs that affect us under our own project's > >funds. > >2. Remove or make ossim dependency optional to OTB > >3. Fork a lite version of ossim into Modules/otbossim/ and cut down as > >much > >as possible. (merging otbossimplugins into otbossim) > > We don't need ossim apps, geos, openthreads, (and jsoncpp) etc.. > > > >First option is what we are doing right now. > > > >Second one is not possible for a short term. > >It will either delay otb releases for a while or will keep the > >packaging > >effort as is. always and only use ossim-1.8.20-3. > > > >With third option, there is no more dependency to OSSIM, GEOS, > >OpenThreads > >in OTB. > >Infact, we keep our "lite" version of ossim under otb's namespace. The > >only > >dependency will be from geotrans library[3] > >This library is currently embedded in ossim library since I can > >remember > >and we will keep this as is for now like 6S and SiftFast. > > > >This forking effort will open doors to explore the possibility to use > >widely available proj4 instead of geotrans. > >That will fix a 5 year blocking issue in OTB! [4] > > > >[3] http://earth-info.nga.mil/GandG/geotrans/ > >[4] https://bugs.orfeo-toolbox.org/view.php?id=701 > > > >This third option will finally get to the second one. (remove > >dependency to > >ossim) > > > >We highly appreciate the work on otb's packaging and it's contribution > >to > >the project. > >But we are not expert in packaging and this the point we like to get > >suggestions from you and DebianGIS team. > > > >What will be the impact on packaging work (we can help with related > >changes) with fork of ossim lite version into OTB sources. ? > > The impact of the embedded copy of the ossim fork should be quite small, > especially when the sources are stripped down to the bare necessities for > OTB (and uses a different SONAME). It makes the fate of the otb package > independent of the ossim package, and that's a good thing in the light of > the concerns raised in this thread. > > Embedded copies are generally frowned upon in Debian. But in this case > with questionable upstream development, using a fork is quite reasonable > for OTB. > Thanks Bas for your reply. Good to know that impact on packaging will be small. We definitely will make sure of it. > >AFAICT, It will be like an embedded copy of ossim and all development > >will > >be detached from upstream project. We only need and use > >only a small part of ossim library. Everything else is out of this > >ossim-lite or otbossim module. If you look, its kind of what they do > >with > >jsoncpp. > > > >For now, there is no action or ongoing work in any direction as you see > >no > >RFCs from OTB side! > > > >Finally, I would also like to say that ossim developers are friendly > >when > >we send bug reports, or patches to OSSIM. > >This was the one thing which kept going for us. But our team is getting > >tired on how the development activities goes in an OSGeo approved > >project. > > The fate of the ossim package lies in the hands of the OSSIM developers, > if the issues raised remain unresolved the package will be removed from > Debian and by extension from Ubuntu. It may also affect its inclusion in > OSGeo-Live, or they may choose to keep the package despite its defects. > > Kind Regards, > > Bas > > -- Regards, Rashad
