[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OSSIM 2.2.0



Hello Bas:

We can use those issues on ossim that people report and integrate those into our backlog to see if we can get customer approval.   Will bring it up at the next standup on the proper process internally to cross match ossim issues to internal JIRA issues and report those as feedback on the ossim issues that are being reported.  Will also verify that issues are being notified across the team just in case one person misses an issue it will get captured.

Will have to talk to the team about reports or subsection of reports that are pulled from change logs and what we can attach to an ossim issue so one can more easily see it.



Take care

Garrett


> On Sep 22, 2017, at 2:57 PM, Sebastiaan Couwenberg <sebastic@xs4all.nl> wrote:
> 
> Hi Oscar,
> 
> On 09/22/2017 08:22 PM, Oscar Kramer wrote:
>> The core OSSIM team reviewed the open issues (113, 114, 115) and as of
>> today those issues are resolved in the dev branches of the ossimlabs
>> collection of repositories. I hope this takes care of any concerns with
>> OSSIM in Debian..
> 
> Thanks for merging Rashads changes and addressing the remaining issues.
> That should resolve the issues with OSSIM 2.x for what the Debian
> package is concerned.
> 
>> Rashad wrote:
>>> 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.
>> 
>> I do not understand Rashad's comment about the issue tracker being kept
>> "far away". It is publicly available on github.com/ossimlabs. This is the
>> tracker we use internally as well, though necessarily separate from ongoing
>> proprietary contracts tasking issues. OSSIM is used in a wide array of
>> projects, not just OTB. We appreciate that OTB is using OSSIM and would be
>> happy to understand what the issues are that is forcing them to fork from
>> the main project.
>> 
>> Regarding the jsoncpp being embedded, that was not an "error" as was
>> pointed out, but an intentional decision to reduce outside dependencies for
>> small packages. I understand the concern and have since removed those files.
>> 
>> Rashad, we have had an open dialog in the past regarding issues
>> encountered. The reason we moved to github was to facilitate outside
>> involvement in the OSSIM open source project. People can do (and have done)
>> pull requests for bug fixes they find. To say that you won't merge with the
>> dev branch because you "keep fixing stuff" is not in the spirit of open
>> source. We would welcome those fixes. Please create a branch and do a pull
>> request. OSSIM dev is bleeding edge and will always have issues. While the
>> core team does its best to keep it running (through dev-ops style building
>> and testing), there are bound to be undiscovered bugs. The reality is that
>> we are getting paid by clients to add new capability and fix bugs we
>> discover. We can't be expected to operate a customer service center for all
>> users of OSSIM. Let's be constructive. What specifically should we do to
>> improve our presence in the open-source eco-system? I'll be the first to
>> say we need more documentation, though we have come a long way in that
>> regard. I also feel we need to be more proactive on issues submitted, but,
>> again, we are not getting paid to fix everything. If someone found a bug,
>> it would be best for them to fix it and use the pull-request function, not
>> just report it as an issue.
> 
> There will be many cases of bugs that users cannot fix themselves,
> providing feedback in the issues they report is the least to be expected
> of the OSSIM project. Users need to know that the issue will be
> addressed by the OSSIM project or if they need to find someone else to
> develop a fix.
> 
> The lack of feedback on the license header issue for example did not
> inspire confidence in the OSSIM project. Adding labels and/or assigning
> issues to a future milestone would be a step in the right direction.
> 
>> In any case, please let us know of any more issues regarding the debian
>> hosting via the github.com/ossimlabs/ossim/issues page, or shoot us an
>> email on the list for general comments and suggestions
> 
> Kind Regards,
> 
> Bas
> 
> -- 
> GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> 


Reply to: