IRC log of 2016.09.05 2:00 PM CEST

[13:20] == grizonnetm [c2c7ac21@gateway/web/freenode/ip.194.199.172.33] has joined #otb
[13:20] == ChanServ [ChanServ@services.] has left #otb []
[13:23] == julien [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has joined #otb
[13:23] == julien has changed nick to Guest58585
[13:28] == Guest58585 has changed nick to jmichel
[14:00] == guillaume__ [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:00] <grizonnetm> hello otb
[14:00] <guillaume__> hello !
[14:02] <grizonnetm> I'm currently updating the agenda for the meeting (it was almost empty)
[14:04] == rkm_ [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:04] <jmichel> hi
[14:05] <jmichel> are we expecting anyone else ?
[14:05] <jmichel> remi ?
[14:05] <jmichel> victor and jordi can not attend
[14:07] <grizonnetm> I'll manage the wiki for this meeting, let me know if you've got something to add to the agenda
[14:09] <grizonnetm> the agenda:
[14:09] <grizonnetm> * Feedback from release 5.6
[14:09] <grizonnetm> * Decision about removal of internal OpenJPEG reader in OTB
[14:09] <grizonnetm> * How to ensure to get documentation of new features from RFC after the merge (examples, cookbook recipes...)?
[14:10] <jmichel> would like to add : GRM and LSGRM integration
[14:11] <jmichel> and perhaps merging courses into cookbook
[14:11] <grizonnetm> ok
[14:12] <guillaume__> I would like to add a small point on Dashboard scripts following Monteverdi integration.
[14:12] <grizonnetm> ok
[14:13] <jmichel> good
[14:13] <jmichel> shall we start ?
[14:14] <grizonnetm> I think so
[14:14] <grizonnetm> Feedback from release 5.6
[14:16] <grizonnetm> nothing to say?
[14:16] <guillaume__> we had delays on the release date
[14:16] <guillaume__> mostly platform issues for packages and pending bugs
[14:17] <guillaume__> 5.6.1 was faster
[14:17] <grizonnetm> is it still usefull to tag a RC1?
[14:18] <guillaume__> I thought RC1 was usefull for pre-release tests, but actually we don't really do this type of test
[14:19] <grizonnetm> Are we agree to apply RFComments 30: http://wiki.orfeo-toolbox.org/index.php/Request_for_Comments-30:_Shorter_release_process ?
[14:19] <grizonnetm> It was not clear for me
[14:19] <jmichel> For me we do not need RC
[14:20] <jmichel> RC is the new X.Y branch
[14:20] <jmichel> you can test it whenever you want, based on nightly packages
[14:20] <grizonnetm> as the framapad does not follow completely orientations of RFC 30: https://framacalc.org/v5CYYNhDXP
[14:21] <jmichel> agree
[14:21] <guillaume__> Release actions needs an update
[14:21] <grizonnetm> ok in this case we should promote the rfcomments to an rfc and then update the "how to release"
[14:22] <jmichel> ok lets do this
[14:22] <jmichel> maybe the release manager role is not clear enough
[14:22] <guillaume__> +1
[14:22] <jmichel> I mean I did the git checkout -b 5.6 and then that was it for me
[14:22] <jmichel> what happens next ?
[14:23] <jmichel> That is where we loose some time
[14:23] <jmichel> should the release manager be responsible for tracking actions in the pad ?
[14:23] <grizonnetm> i think so
[14:23] <jmichel> ok that needs to be clarified
[14:24] <guillaume__> We often have cases were issues are spotted during release process. The release manager should say if this is blocking or not
[14:24] <jmichel> yes ok
[14:24] <grizonnetm> update in "how to release" are I think very limited
[14:24] <jmichel> someone has to decide
[14:25] <jmichel> same thing for minor release
[14:25] <jmichel> when is a minor release required ?
[14:26] <grizonnetm> I see it as an "on demand" release which adress critical issues, regressions, important documentation or compiler support...
[14:27] <grizonnetm> difficult to have clear rules to decide when we need a bugfix release
[14:28] <jmichel> ok but who decides ?
[14:29] <guillaume__> release manager ?
[14:30] <grizonnetm> PSC?
[14:30] <grizonnetm> I don't know
[14:31] <jmichel> I think RM should be responsible for the release from start to end
[14:31] <guillaume__> +1
[14:31] <grizonnetm> +1
[14:32] <grizonnetm> let's add this to RFC 30
[14:33] == cresson [~cresson@mtd201.teledetection.fr] has joined #otb
[14:33] == cresson_ [c130bdc9@gateway/web/freenode/ip.193.48.189.201] has joined #otb
[14:34] == cresson_ [c130bdc9@gateway/web/freenode/ip.193.48.189.201] has quit [Client Quit]
[14:34] <cresson> hello
[14:34] <grizonnetm> hi
[14:34] <guillaume__> hi
[14:35] <jmichel> good
[14:35] <jmichel> hi remi
[14:35] <cresson> my apologies for the delay, lot of people at the restaurant
[14:38] <grizonnetm> ok
[14:38] <grizonnetm> so we're discussing adjustements to the release process
[14:39] <jmichel> we decided to extend a bit the role of release manager to :
[14:39] <grizonnetm> we're agree to update RFComments 30 and make an RFC from it (and comments from the PSC meeting regarding bugfix release, RM responsabilities...)
[14:41] <cresson> ok
[14:41] <cresson> what is exaclty new for the RM
[14:42] <jmichel> and also RM will track actions from branching to final release, and decide when to do minor releases
[14:43] <jmichel> ok
[14:43] <grizonnetm> other feedback from release 5.6?
[14:44] <jmichel> a great deal of RFC
[14:46] <jmichel> anything else ?
[14:47] <jmichel> or can we move on ?
[14:47] <cresson> Yes we can !
[14:47] <grizonnetm> one problem I see (not specific to release 5.6) is that we don't know how many people download OTB after the release
[14:47] <guillaume__> ok
[14:47] <grizonnetm> I think it's missing
[14:47] <grizonnetm> I've started a discussion on otb-dev about this
[14:48] <grizonnetm> 2 weeks ago
[14:48] <jmichel> good point. No more nice charts for slides since we moved out of sourceforge
[14:48] <jmichel> I think we have the data somewhere in server supervisor
[14:48] <jmichel> If OTB was an android app, we could get a lot of info on our users )
[14:49] <jmichel> ;)
[14:49] <grizonnetm> ITK is still using sourceforge
[14:49] <guillaume__> I thought we had some monitoring on the website
[14:50] <grizonnetm> PSC members at minimum should be able to find this information somewhere
[14:52] <jmichel> agree
[14:52] <cresson> agree too
[14:52] <jmichel> we need to see this with sebastien
[14:52] <grizonnetm> ok
[14:52] <grizonnetm> I add this to the wiki
[14:52] <grizonnetm> next?
[14:53] <jmichel> OpenJPEG ?
[14:53] <grizonnetm> ok
[14:53] <grizonnetm> Decision about removal of internal OpenJPEG reader in OTB
[14:54] <jmichel> +1
[14:54] <jmichel> next ;)
[14:55] <jmichel> this is confusing for users
[14:55] <grizonnetm> :)
[14:55] <jmichel> plus find openjpeg is buggy
[14:55] <guillaume__> +1
[14:56] <grizonnetm> ok so we need an RFC to make the code deprecated in 5.8
[14:57] <jmichel> do we ?
[14:58] <jmichel> is someone calling JPEG2000ImageIO directly ?
[14:59] <grizonnetm> i don't think so
[15:00] <jmichel> ok
[15:00] <jmichel> maybe we can remove it directly
[15:01] <jmichel> I do not mind to mark it deprecated first, but I would like to be sure it gets removed someday ;)
[15:01] <jmichel> Side proposal : deprecated class can only be deprecated for one release. After that, either they get remove or undeprecated
[15:02] <guillaume__> This is something we can add in the how-to-release ...
[15:03] <guillaume__> direct removal or deprecated are both fine for me
[15:03] <grizonnetm> I think that currently there are only classes in SVMLearning which are deprecated in OTB
[15:03] <grizonnetm> but they are here for a long time that's true
[15:05] <grizonnetm> direct removal also fine for me
[15:05] <grizonnetm> next topic?
[15:05] <grizonnetm> Dashboard scripts following Monteverdi integration
[15:06] <grizonnetm> Guillaume?
[15:06] <guillaume__> I wanted to discuss this point only because Monteverdi will soon be integrated
[15:06] <guillaume__> and it would be the right moment to apply some refactoring on the dashboard scripts,
[15:06] <guillaume__> there was an RFComment in that way
[15:07] <guillaume__> http://wiki.orfeo-toolbox.org/index.php/Request_for_Comments-18:_Factorize_CMake_configuration
[15:08] <jmichel> why not
[15:08] <jmichel> but this sounds like a lot of work
[15:09] <guillaume__> it depends on the final objectives
[15:09] <guillaume__> we could start to standardize things between different platforms
[15:10] <guillaume__> for me, the benefit would be to have simpler scripts.
[15:10] <jmichel> ok
[15:11] <jmichel> others, do you have an opinion on this ?
[15:12] <cresson> not reall
[15:12] <cresson> y
[15:12] <guillaume__> Victor should have an opinion since he wrote the RFC
[15:13] <grizonnetm> not really also
[15:13] <grizonnetm> agree that ITK got simpler scripts: https://open.cdash.org/viewNotes.php?buildid=4534145
[15:14] <grizonnetm> don't know if it is because they use more standard directory organizations of if it is because they've got less cmake options as OTB :)
[15:15] <grizonnetm> I agree however on the fact that Config in OTB-DevUtils is really messy
[15:15] <grizonnetm> with lots of old platforms and scripts that can be removed
[15:15] <guillaume__> +1 for cleaning
[15:16] <rkm_> i did some work on adding scripts for windows and travis which was interersting
[15:16] <rkm_> the idea was to force "xdk" and a single dashboard cmake file dashboard.cmake
[15:17] <rkm_> with two launcher scripts
[15:17] <rkm_> dashboard.sh and dashboard.bat
[15:17] <rkm_> and that was end of my configuraiton. infact dashboard.bat i used in two windows without a less mess ups!
[15:19] <grizonnetm> so let's restart the discussion on otb-developers about this (difficult to discuss here without Victor who wrote the RFC IMHO)
[15:19] <jmichel> +1 for cleaning there are so much files in OTB-DevUtils/Config
[15:19] <jmichel> Victor is arriving
[15:20] == VictorPoughon [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has joined #otb
[15:20] <jmichel> tadaaa
[15:20] <cresson> hi Victor
[15:20] <VictorPoughon> hi everyone
[15:22] <guillaume__> hi Victor, we were talking about Dashboard script factorization
[15:22] <VictorPoughon> ok
[15:23] <guillaume__> I proposed that, once Monteverdi is merged, it would be the right time to look at it
[15:23] <guillaume__> we all agreed that, at least, some cleaning can be done in DevUtils/Config
[15:24] <grizonnetm> good
[15:25] <VictorPoughon> Yes maybe. Another idea to put on the table is to leverage the superbuild much more. Because dpeendency installation and updating is a big part of build servers maintenance, using the superbuild to standardize it accross plateforms could save a lot of manpower
[15:25] <VictorPoughon> So we'd create a SuperBuild-ThirdPartyTrunk branch for example
[15:26] <VictorPoughon> Although it could be argued that the heterogeneity of build server is a feature not a bug
[15:26] <VictorPoughon> I don't know
[15:27] <guillaume__> I think the heterogeneity of build servers is what we want
[15:28] <guillaume__> (regarding configuration and dependencies)
[15:28] <rkm_> agreed with guillaume, what we need to test is OTB and version  of dependenceis listed in superbuild works with OTB. if ossim/gdal/... has issue with gcc 3.3/gcc8 that is a another problem
[15:28] <VictorPoughon> So is using system dependencies as much as possible a requirement for the dashboard infrastructure? In order to maximize the number of difference configurations?
[15:28] <grizonnetm> Think we need to keep this heterogeneity
[15:29] <rkm_> tests failing due to version problem in dependencies is not fun.
[15:29] <rkm_> it is funny!
[15:30] <grizonnetm> for me submissions should use a maximum of system dependencies
[15:31] <grizonnetm> apart from superbuild submissions which should compile most third party (default behavior of the superbuild)
[15:32] <rkm_> using a variety of sys dependencies was most of reason we have failing test and multi-baslines
[15:32] <VictorPoughon> But currently some plateforms (pc-christophe for example) use a lot of non system dependencies which are configured, updated and built by shell scripts. In the end we are re-writing a poor clone of CMake's add_ExternalProject, which is itself a half-brother of apt-get/yum.
[15:32] <rkm_> and finally test may fail with superbuild because baseline is working a verision of gdal or hdf which nobody knows which version
[15:33] <guillaume__> Even if our all-in-one package solve a lot of portability issues, it would be nice to ensure OTB can work with the official environment
[15:33] <jmichel> I would like to suggest that we solely support gentoo starting 5.8
[15:33] <jmichel> emerge otb
[15:33] <jmichel> and that is it
[15:33] <rkm_> what about "OTB works with most of version of external dependencies. Not everything is tested
[15:34] <guillaume__> Problems with test and baselines are also linked with the testing strategy that should be more independant from 3rd parties
[15:34] <rkm_> see a dozen deps and keeping track of N versions of everything is itself is a lot of developer work for 1% of beneifit
[15:35] <rkm_> @julien, does gentoo has "only free software license" policy?
[15:36] <jmichel> on the other hand, if we only keep superbuild versions, we can not foresee and correct problems related to other versions
[15:36] <VictorPoughon> jmichel: we could with a SuperBuild-ThirdPartyTrunk, which does "git clone master" for all dependencies
[15:37] <VictorPoughon> maybe?
[15:37] <jmichel> the problem is if one is broken, everything is
[15:38] <jmichel> for instance it is a good thing that OTB is both compatible with gdal 1.X and 2.X
[15:38] <jmichel> but that needs to be tested, otherwise ...
[15:38] <VictorPoughon> jmichel: oh yes then we go crazy and make a [SuperBuild-trunk-X branch for X in (all of OTB dependencies)]
[15:39] <VictorPoughon> And the SuperBuild-trunk-all branch is a git octopus merge of all the above
[15:40] <rkm_> for sanity (not for me). I would say support only superbuild versions. if  there is an issue is itk trunk , we don't know. but we will when they release it and we add it in superbuild
[15:40] <rkm_> i mean there is a RFC for update of thirdparties in SB. so we might know
[15:40] <rkm_> if we go trunk, we must go from gcc, -> muparserx. so for sanity i won't say that
[15:41] <VictorPoughon> rkm_: why gcc?
[15:41] <rkm_> having a bug discovered in itk, ossim, gdal trunk is rare and mostly get fixed before release
[15:41] <rkm_> why not gcc?
[15:41] <rkm_> recently i got a bug from libdl?
[15:41] <VictorPoughon> I mean why to you say we must "go from gcc"?
[15:41] <rkm_> can you imagine testing that on dashboard
[15:42] <rkm_> the problem is where do we draw a line and say NO.
[15:42] <rkm_> that is my point, the bug in itk trunk might be from gcc6 or maybe some other libs
[15:42] <rkm_> to sumup, what we gain vs what we spent is to be looked
[15:43] <rkm_> the gain must be lower than cost
[15:43] <rkm_> cost is money or develoepr time or whatever
[15:43] <VictorPoughon> rkm_: +1
[15:43] <jmichel> maybe this is a bit of topic wrt "shall we cleanup and reorganize dashboard scripts ?"
[15:44] <guillaume__> yes, the initial topic was not about changing the dashboard strategy
[15:44] <rkm_> we can keep discss further on list or irc afer irc meeting
[15:45] <VictorPoughon> My main issue I think is that there is duplicated code between the superbuild's add_externalproject and each platforms' update_gdal.sh (& co). So I think a policy like "build servers may use either SuperBuild or system dependencies, but nothing else (i.e. no manual update/configure)" would be a good idea
[15:45] <jmichel> VictorPoughon: +1
[15:46] <jmichel> that makes sense : either superbuild or system lib
[15:46] <grizonnetm> ok
[15:46] <grizonnetm> can we move to the next topic?
[15:46] <jmichel> actually, that may be 2 kinds of superbuild builds : use as much/as many system deps
[15:47] <VictorPoughon> jmichel: yes something like that
[15:47] <guillaume__> ok
[15:48] <grizonnetm> GRM and LSGRM integration
[15:48] <jmichel> cresson, glad you are here
[15:48] <jmichel> I think we should have both integrated in OTB
[15:49] <jmichel> to give them correct exposure (cf. mails on otb-users)"
[15:49] <cresson> yes but LSGRM is still buggy
[15:49] <jmichel> how much buggy ?
[15:50] <jmichel> we can start a feature branch, and it will be tested nightly
[15:50] <cresson> segmentation output are not 100% identical as they should be, I am still investigationg this bug
[15:50] <jmichel> ok
[15:50] <jmichel> but is it really blocking
[15:50] <jmichel> ?
[15:50] <cresson> more critical is its depend of tiling layout
[15:51] <cresson> as the output segmentation is not fully reproductile (i.e different tiling layout but same parameters) I would say yes it is blocking
[15:52] <jmichel> ok
[15:52] <jmichel> but maybe we can work together on that
[15:52] <cresson> absolutely
[15:52] <jmichel> I think having both LSMS and LSGRM would be great
[15:53] <cresson> yes, and now LSGRM depends GRM wich is great
[15:53] <jmichel> can we plan this for 5.10 ?
[15:53] <jmichel> we might be a bit short for 5.8
[15:53] <cresson> developpers can also implement their own criterion using Pierre's template of GRM and extend it to LSGRM
[15:53] <cresson> yes 5.10
[15:53] <jmichel> or maybe 5.10 = 6.0 ?
[15:54] <VictorPoughon> in base 4 maybe
[15:55] <jmichel> ok so that is settled for LSGRM
[15:56] <jmichel> One small thing I would like to discuss is C++11 / OpenMP support
[15:56] <jmichel> we will soon have modules that only work with C++11
[15:56] <jmichel> and also modules that would rather be used with OpenMP
[15:57] <jmichel> I was looking for a mechanism to activate C++11 / OpenMP automatically if available
[15:57] <jmichel> and that disables modules that depend on them if not
[15:57] <jmichel> my first idea was to have OpenMP and C++11 as third party modules
[15:57] <jmichel> but that does not work
[15:57] <guillaume__> that looks like the 3rd party mechanism
[15:57] <jmichel> no
[15:58] <jmichel> because to activate openmp / C++11, you need to set compiler flags at project level
[15:58] <jmichel> and that is something that can not be done in the cmake of a module
[15:59] <cresson> and setting flags inside incriminated modules?
[15:59] <jmichel> I think this is not safe
[16:00] <jmichel> if you build OTB with C++11, everything should be built with it, and the FindOTB.cmake should even check for C++11
[16:00] <guillaume__> Then we could extend a bit the module mechanism, to handle REQUIRED_FLAGS in otb-module.cmake
[16:01] <grizonnetm> moreover I think that with cmake  you can not be changed CMAKE_CXX_COMPILER options after the first cmake or ccmake run
[16:01] <grizonnetm> see https://cmake.org/Wiki/CMake_Useful_Variables#Compilers_and_Tools
[16:01] <jmichel> compiler no, but flags you can
[16:01] <jmichel> guillaume__: that would be a start
[16:02] <jmichel> the other thing would be to activate c++11 openMP if available
[16:02] <guillaume__> I think we can test C++11 support using cmake try_compile
[16:02] <guillaume__> same for OpenMP
[16:04] <jmichel> guillaume__: there is actually a FindOpenMP.cmake that does that
[16:04] <jmichel> but do we activate by default ?
[16:05] <guillaume__> It is enabled to compile SiftFast
[16:06] <guillaume__> I don't think it is propagated to OTB project
[16:08] <guillaume__> what is the risk of enabling it by default ?
[16:10] <jmichel> we will not be able to build otb without it ?
[16:10] <jmichel> maybe someone will want to ?
[16:13] <jmichel> ok will see
[16:13] <guillaume__> If we have an option to disable it, this should be ok
[16:13] <jmichel> next topic ?
[16:14] <cresson> ok
[16:14] <guillaume__> Merging courses into the cookbook
[16:14] <VictorPoughon> +1 but that yields the issue of cookbook i18n
[16:15] <jmichel> yes
[16:16] <guillaume__> +1
[16:16] <VictorPoughon> And also polute the git log quite a bit because typically otb-documents/Courses activity is much more active than develop. So I have mixed feelings actually
[16:18] <VictorPoughon> still +1 for me
[16:18] <guillaume__> The commit prefix will become essential to separate code from documentation
[16:18] <guillaume__> all commits to SG, CB and courses should be "DOC: ...."
[16:19] <VictorPoughon> Another way to filter is by directory: "git log Documentation/" will for fine
[16:19] <jmichel> also we would need to org->latex->rst->wtf
[16:19] <VictorPoughon> my guess is pandoc can do org->rst directly
[16:20] <grizonnetm> or this: https://github.com/masayuko/ox-rst
[16:20] <VictorPoughon> ok I can take that action since I worked on cookbook recently
[16:20] <grizonnetm> also have mixed feeling to polute develop branch with commits related to the documentation...
[16:20] <grizonnetm> but let's see how it works
[16:22] <jmichel> git squash ?
[16:22] <VictorPoughon> git aubergine
[16:22] <jmichel> to avoid commits fixing typos & co
[16:25] <VictorPoughon> next topic?
[16:25] <grizonnetm> next RM?
[16:27] <VictorPoughon> any volunters?
[16:27] <cresson> I would be, but I will not be here between 8->24 oct and also 7->11 nov
[16:27] <jmichel> we should have a rule such as lower nb of lines of code in last release
[16:27] <rkm_> so i can't be
[16:28] <VictorPoughon> jmichel: rm * wins then
[16:28] <grizonnetm> I can be the next RM
[16:29] <VictorPoughon> +1 for grizonnetm  and cresson as backup
[16:29] <cresson> ok
[16:29] <cresson> +1
[16:29] <guillaume__> +1
[16:29] <jmichel> +1
[16:29] <grizonnetm> thanks
[16:29] <VictorPoughon> thanks all
[16:29] <cresson> next one, I'll take the shot
[16:29] <jmichel> bye
[16:29] <jmichel> thanks
[16:29] <grizonnetm> I've to go
[16:30] <grizonnetm> bye