Meetings minutes

From OTBWiki
Jump to: navigation, search

menu Status #otbX

  1. otb: (no topic set)

[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