IRC logs Monday 2017.02.27 3:00 PM CEST

#otb: (no topic set)
[14:27] == guillaume_ [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:27] <guillaume_> hi everyone !
[14:27] == Ludovic [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:28] == cresson [~cresson@mtd201.teledetection.fr] has joined #otb
[14:28] <cresson> Hello
[14:29] <Ludovic> Hi
[14:30] <guillaume_> hi
[14:34] == rkm [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:41] == rkm [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has quit [Quit: Page closed]
[14:42] <guillaume_> I think the CNES guys will be there around 3pm
[14:42] <guillaume_> Victor and Julien are missing
[14:43] <cresson> yep
[14:44] == rkm [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:56] <grizonnetm> hi
[14:56] <cresson> hi
[14:56] == VictorPoughon [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has joined #otb
[14:57] <VictorPoughon> Hello sorry for being late
[14:58] <cresson> no problem
[15:00] <guillaume_> hi
[15:05] == jmichel [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has joined #otb
[15:05] <jmichel> hi
[15:05] <jmichel> apologize for the delay
[15:05] <jmichel> I thought it was 3 PL
[15:05] <jmichel> PM
[15:05] <VictorPoughon> guillaume_: are we ready to start? can you handle the agenda?
[15:06] <guillaume_> yes ready
[15:06] <grizonnetm> ready
[15:06] <guillaume_> First item on agenda : Feedback from release 5.10
[15:07] <grizonnetm> feedbacks from the release manager?
[15:07] <guillaume_> As usual, some heavy bugs and packaging issues slowed us
[15:08] <guillaume_> but the content (in term of features  , bugfix) is good
[15:09] <jmichel> one thing that surprised me was broken packages
[15:09] <guillaume_> The release process in itself is light (no hard work on the day of release)
[15:09] <jmichel> I thought we had this covered
[15:09] <guillaume_> packages on windows ?
[15:09] <cresson> Windows packages with Mosaic were greatly appreciated :P
[15:09] <cresson> sad GRM was not here too
[15:10] <jmichel> And linux ones
[15:11] <guillaume_> About linux : this is the first release where we moved to a more recent build platform (and enabled c++11)
[15:11] <guillaume_> most of the troubles come from this upgrade
[15:11] <VictorPoughon> For me this is acceptable because we did not release anything that was broken (which we've done in the past). It's ok to have intermediate versions on develop broken, this is why we test and have a bugfix process
[15:12] <guillaume_> yes, what we see also is that detecting this issues early will help for fast releases
[15:12] <grizonnetm> it would be nice to automate a set of minimum tests run every night against a standalone package (launch monterverdi, run an application...)
[15:13] <jmichel> guillaume_, grizonnetm, that was my point
[15:13] <rkm> +10 on testing
[15:13] <guillaume_> ok so +1 on that
[15:13] <jmichel> +10k
[15:13] <cresson> yes
[15:14] <VictorPoughon> Also a small problem for me is that some days Windows nightly packages are not there (but this is a known infrastructure issue)
[15:14] <rkm> i have a plan for testing
[15:14] <jmichel> also, as usual we did a training with 5.8 3 days after feature freeze so we came back with a ton of bugs to fix
[15:14] <rkm> should we or should we not skip a remote module build if the repository of that module is offline
[15:15] <VictorPoughon> jmichel: this is a good thing, isn't it?
[15:15] <jmichel> rkm, skip
[15:15] <rkm> because that is a fix in cmake module macros:
[15:15] <cresson> yes  skip
[15:15] <guillaume_> VictorPoughon: better late than never
[15:15] <jmichel> VictorPoughon, yes but it would be better to have the training between releases so that there is plenty of time to fix bugs
[15:17] <VictorPoughon> ok that's nice but is there something for the PSC to decide here?
[15:17] <jmichel> no of course not
[15:17] <guillaume_> we could come back to the package testing strategy ?
[15:17] <jmichel> but we could set some rules here to avoid one month of bug-fixes after feature freeze
[15:17] <VictorPoughon> add fewer bugs :)
[15:17] <jmichel> guillaume_: you want to discuss details here ?
[15:18] <grizonnetm> What PSC can decide: setup a minimal infrastructure to test standalone packages automatically before the next feature freeze
[15:18] <guillaume_> maybe if people have something to say
[15:19] <guillaume_> that's the point : where start and ends a "minimal infrastructure to test packages" ?
[15:20] <guillaume_> we can easily check that the package can be deployed and that executables can be launched, and no dynamic linkage error happens
[15:20] <guillaume_> Testing the behaviour of application requires more tools
[15:21] <VictorPoughon> https://xkcd.com/1319/
[15:22] <cresson> lol
[15:22] <VictorPoughon> Is the effort to automate this going to be worth it? Is it really hard to download -> run package every few days? (Monteverdi, GUI, many platforms, etc.)
[15:23] <guillaume_> I agree, maybe human testing on a regular basis is enough
[15:23] <rkm> the key to testing packages is do it using cmake and cmake only. cmake can have custom target to extract the package , run some otbcli_* and see the output
[15:23] <jmichel> human testing == untesting
[15:23] <rkm> without writing extra code. since cmake is cross plat, there is less work for other platforms
[15:24] <rkm> you don't need to download to verfiy packages. extract and run some test + md5sum will do
[15:24] <VictorPoughon> rkm: ok but what about Monteverdi, Mapla, PEBCAK, etc. ?
[15:25] <rkm> gui testing is either manual or very expensive automation.
[15:25] <guillaume_> rkm: okay to use cmake if possible, but more important is to see what can be tested
[15:25] <rkm> VictorPoughon: if we look stats from last releases: most issues such as crash in app, missing dlls.. etc.. could be solved with the first one
[15:26] <jmichel> I think we should only run all executable and see that there are no segfault / link error
[15:26] <jmichel> the remaining is the job of nightly testing
[15:26] <VictorPoughon> Yes but we still need manual tests to catch all of them anyway
[15:28] <grizonnetm> +1 to start by only running all exe and see that there are no segfault / link error
[15:28] <VictorPoughon> +1
[15:29] <guillaume_> yes +1 for the minimal check of each executable
[15:29] <VictorPoughon> no actually +0
[15:29] <cresson> +11
[15:30] <guillaume_> VictorPoughon: you think we should go for a tool to test the GUI application behaviour ?
[15:30] <cresson> I don't fully realize the testing issue of gui myself
[15:31] <VictorPoughon> guillaume_: no I think adding tests to binary package is redundant work because we will still need to do the manual checks to catch GUI bugs
[15:32] <VictorPoughon> But I'm ok if we vote to do it, hence +0
[15:32] <guillaume_> those packages test are not redundant
[15:32] <guillaume_> they will spot issues sooner
[15:33] <VictorPoughon> I suspect we will spend more time fixing issues with the code that tests the binary packages than will be saved by spotting those issues sooner
[15:33] <guillaume_> about Gui bugs, that's where we need different testing tools, and this can be independant of packages
[15:34] <guillaume_> About packages test, I am more confident, checking binaries is not that hard
[15:35] <guillaume_> What I think of is really a minimal package test : uncompress , check ldd output on each binary, launch monteverdi, launch mapla
[15:37] <VictorPoughon> ok, jmichel , cresson votes ?
[15:37] <jmichel> +1
[15:37] <guillaume_> I think every one has voted
[15:37] <cresson> yep I did put my +1 for testing app running
[15:38] <VictorPoughon> ok good
[15:38] <VictorPoughon> next topic
[15:38] <guillaume_> Next is : Choose new Release Manager
[15:38] <guillaume_> Candidates ?
[15:38] <cresson> This time I can be
[15:38] <VictorPoughon> +1 for cresson
[15:39] <guillaume_> +1 for cresson , a name for backup RM ?
[15:39] <jmichel> +1
[15:40] <cresson> I think this time I can be fully operational on Git, but I might need a little help is I screw something
[15:40] <cresson> *if
[15:41] <VictorPoughon> ok I can be backup, you can ask me if need be
[15:41] <cresson> ok
[15:41] <guillaume_> Ok so RM = cresson  , and Backup RM = Victor
[15:42] <cresson> ok
[15:42] <guillaume_> Next topic is :  6.0 roadmap
[15:44] <VictorPoughon> How about take advantage of the major number increment to remove some old deprecated classes/files?
[15:44] <guillaume_> currently there is work on upsupervised learning
[15:44] <guillaume_> Yes, that's the moment to do this cleaning
[15:45] <VictorPoughon> ok action for the minute: survey candidates for deletion and write RFComments
[15:46] <grizonnetm> RFC for moving to Apache will be voted this week normally
[15:46] <grizonnetm> there is also lots of easy cleaning that can be done with classes which are deprecated for more than 2 releases
[15:47] <grizonnetm> voted -> submitted
[15:47] <jmichel> ok but beware of deprecated code that is still used somewhere in OTB ...
[15:48] <guillaume_> yes, +1 for removal of deprecated classes.
[15:48] <guillaume_> jmichel: of course :)
[15:49] <jmichel> maybe it would be a good point to fix this once and for all
[15:49] <jmichel> for instance, LibSVMMachineLearningModel depends on SVMModel, that is deprecated
[15:49] <VictorPoughon> let's "git rm $(grep -L deprecated *)" on a branch, submit to dashboard and take it from there :D
[15:49] <jmichel> I think there are other examples
[15:50] <jmichel> VictorPoughon: I do not need manual testing to tell you that this will not build (probably even not configure)
[15:50] <guillaume_> you think there are deprecated classes that we actually need ?
[15:50] <jmichel> no, I think that some lazy guy has used some deprecated code to write new feature
[15:51] <jmichel> No names
[15:51] <guillaume_> ok so it means that some features have to be rewritten without deprecated code
[15:51] <jmichel> yes
[15:51] <VictorPoughon> ok action: survey all deprecated classes and files, since which version, and is it used in OTB code. Put it into a RFComments ?
[15:51] <jmichel> LibSVMMachineLearningModel
[15:52] <jmichel> VictorPoughon: +1
[15:52] <cresson> VictorPoughon, +1
[15:52] <jmichel> git log will give you (my) name
[15:53] <guillaume_> +1 for the survey
[15:55] <guillaume_> Ok so aside from Licence migration and deprecated cleanup, what do we have for 6.0 ?
[15:55] <jmichel> ok, anything else for 6.0 ?
[15:55] <VictorPoughon> 2 RFC merged already
[15:55] <jmichel> Still some lost treasures to undig
[15:55] <jmichel> and unsupervised convergence
[15:55] <jmichel> s/undig/dig/
[15:57] <cresson> I will propose a new remote module
[15:57] <grizonnetm> we're still "in midstream" regarding sar sensors in otb
[15:57] <cresson> but might be just a new RFC
[15:57] <grizonnetm> we've got the new implementation of s1
[15:58] <grizonnetm> but other sensors have not been migrated yet
[15:59] <grizonnetm> don't want to add this to 6.0, just want to list what we've got "in progress"
[15:59] <jmichel> cosmo has, no ?
[15:59] <jmichel> or TSX
[15:59] <jmichel> but porting sensor model is very expensive
[15:59] <grizonnetm> sorry we've got an implementation of TSX with the new sensor classe without the support of GRD
[16:01] <guillaume_> I fear that if we keep this migration on hold for too long, it will be buried
[16:02] <guillaume_> or at the time we resume, we will already have removed ossim from otb :)
[16:02] <grizonnetm> don't see other big refactoring or migration for 6.0
[16:03] <grizonnetm> we've got still a lot of smaller items in the wishlist
[16:03] <grizonnetm> Agustin in particular has posted lots of improvments for existing applications recently
[16:03] <jmichel> and we have very active users that require better OBIA
[16:04] <VictorPoughon> grizonnetm: +1 for tackling some low hanging fruits
[16:04] <jmichel> I will probably have some code to share
[16:04] <jmichel> I would not call sar model port low hanging ;)
[16:05] <guillaume_> the local contrast feature seems interesting for Ice/monteverdi
[16:07] <grizonnetm> got some code to share also regarding multi-temporal processing (DTW, DBA) recently discuss on otb-users
[16:09] <jmichel> guillaume_: not really
[16:10] <cresson> I agree grizonnetm
[16:10] <jmichel> this can not be implemented as shaders
[16:10] <jmichel> has to be processed offline
[16:10] <guillaume_> too bad ...
[16:10] <jmichel> it depends on the  method
[16:10] <jmichel> but I would say most methods can not
[16:12] <guillaume_> I had one point about remote modules : should we package the remote modules from Jordi that require GSL ?
[16:13] <cresson> If we do so we might change the official remote modules policy
[16:13] <guillaume_> this would give at least 3 additional remote modules
[16:15] <jmichel> is it easy ?
[16:15] <guillaume_> well, you're right, the policy explicitely tells it
[16:15] <grizonnetm> don't know how hard it is to build gsl with recent msvc
[16:15] <grizonnetm> did some research recently
[16:16] <grizonnetm> it does not seem straightforward
[16:16] <jmichel> ok so I would say no
[16:16] <guillaume_> ok fine
[16:17] <grizonnetm> but it did not cost a lot to give it a try
[16:17] <cresson> a colleague is also about to propose a new remote module for OBIA
[16:18] <grizonnetm> nice!
[16:19] <cresson> a lot of incoming new remote modules for 6.0 ...
[16:20] <grizonnetm> hope we will be able to package them
[16:20] <jmichel> yes
[16:20] <cresson> yep
[16:20] <jmichel> maybe we should work on moving code from remote to core
[16:21] <VictorPoughon> For currently packaged modules it's only a political decision, for those with new dependencies it's a technical one
[16:22] <grizonnetm> agree with Julien
[16:22] <VictorPoughon> 6.0 is a good time to do this, so +1 to investigate candidate modules
[16:22] <guillaume_> jmichel: does it mean copy the remote module into new core module ?
[16:23] <guillaume_> I mean : we keep the module un-touched, just move it to a different group ?
[16:24] <jmichel> guillaume_: not sure
[16:24] <jmichel> we might want to review code
[16:24] <jmichel> or change this or that
[16:24] <jmichel> we have little requirements on how the remote module is writtent
[16:24] <jmichel> -t
[16:25] <jmichel> we have more requirements for core modules
[16:25] <VictorPoughon> Sounds like a normal RFC, no?
[16:25] <VictorPoughon> Also license must be OTB license
[16:25] <grizonnetm> contributor licence agreement...
[16:25] <jmichel> VictorPoughon: yes
[16:25] <grizonnetm> we could start with the mosaic module from remi
[16:26] <jmichel> why not, if Remi agrees
[16:26] <jmichel> Authors agreement is mandatory
[16:27] <cresson> yes, I agree. However for the licence agreement I should refer to Irstea
[16:27] <jmichel> yes
[16:28] <jmichel> But maybe the SERTIT object module is interesting
[16:28] <jmichel> it increases OBIA in OTB
[16:28] <jmichel> and I am not sure it is really maintained
[16:28] <cresson> code reviewers migh go crazy, it will also require a little work before the process
[16:29] <cresson> I think the GRM and incoming LSGRM are also very attractive too
[16:30] <cresson> I don't know a lot of RS software which perform exact large scale generic region merging
[16:30] <jmichel> yes
[16:30] <jmichel> I think we will have a remote module for that quite soon
[16:30] <guillaume_> +1 to choose a remote module and try to move it to core
[16:31] <jmichel> but it will need to stay remote for a while
[16:31] <cresson> yes
[16:33] <guillaume_> ok so do we choose a remote module now ? you want to try SertitObject first ?
[16:33] <cresson> Action: let's try it on SERTIT/Mosaic?
[16:34] <guillaume_> +1
[16:34] <grizonnetm> ok
[16:34] <cresson> +1
[16:34] <VictorPoughon> +1
[16:36] <grizonnetm> next topic?
[16:36] <VictorPoughon> who does the meeting summary on the wiki?
[16:36] <guillaume_> That was the last topic on agenda
[16:36] <guillaume_> I can do the summary
[16:36] <guillaume_> anything left to conclude ?
[16:37] <grizonnetm> got 35 answers for the survey on how to improve otb integration in qgis
[16:38] <grizonnetm> I'll try to write a summary on the blog in March
[16:38] <VictorPoughon> grizonnetm: great
[16:38] <cresson> nice
[16:38] <cresson> do you know when QGIS will have the new OTB integration framework?
[16:38] <cresson> which version
[16:39] <guillaume_> I thought it was already done (migration of OTB plugin outside official QGis processing module)
[16:39] <grizonnetm> what do you mean exactly  by "nex integration framework"?
[16:40] <grizonnetm> s/nex/new
[16:40] <cresson> moving from xml files to use of the API
[16:42] <cresson> http://osgeo-org.1560.x6.nabble.com/OTB-and-LiDAR-tools-as-separate-plugins-td5305313.html
[16:42] <grizonnetm> no plan yet to the best of my knowledge
[16:42] <VictorPoughon> this PR has been merged on QGIS side : https://github.com/qgis/QGIS/pull/4076
[16:43] <cresson> ok
[16:44] <VictorPoughon> It's clear we need to spend some time on QGIS - OTB integration
[16:45] <VictorPoughon> But anything else that concerns the PSC?
[16:45] <grizonnetm> nothing left for me
[16:45] <grizonnetm> thank you
[16:46] <VictorPoughon> ok thank you all
[16:46] <grizonnetm> don't forget to save the logs on the wiki
[16:46] <jmichel> thank you all, bye
[16:46] <grizonnetm> bye
[16:46] <guillaume_> yes, thank you all
[16:46] <guillaume_> bye
[16:46] <cresson> same, thank you