irc

gistfile1.txt

[14:06] == rkm_ [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:06] <jmichel> hi
[14:06] <jmichel> are we expecting anyone else ?
[14:06] <jmichel> remi ?
[14:07] <jmichel> victor and jordi can not attend
[14:09] <grizonnetm> I'll manage the wiki for this meeting, let me know if you've got something to add to the agenda
[14:11] <grizonnetm> the agenda:
[14:11] <grizonnetm> * Feedback from release 5.6
[14:11] <grizonnetm> * Decision about removal of internal OpenJPEG reader in OTB
[14:11] <grizonnetm> * How to ensure to get documentation of new features from RFC after the merge (examples, cookbook recipes...)?
[14:12] <jmichel> would like to add : GRM and LSGRM integration
[14:12] <jmichel> and perhaps merging courses into cookbook
[14:13] <grizonnetm> ok
[14:13] <guillaume__> I would like to add a small point on Dashboard scripts following Monteverdi integration.
[14:14] <grizonnetm> ok
[14:15] <jmichel> good
[14:15] <jmichel> shall we start ?
[14:16] <grizonnetm> I think so
[14:16] <grizonnetm> Feedback from release 5.6
[14:17] <grizonnetm> nothing to say?
[14:18] <guillaume__> we had delays on the release date
[14:18] <guillaume__> mostly platform issues for packages and pending bugs
[14:19] <guillaume__> 5.6.1 was faster
[14:19] <grizonnetm> is it still usefull to tag a RC1?
[14:20] <guillaume__> I thought RC1 was usefull for pre-release tests, but actually we don't really do this type of test
[14:21] <grizonnetm> Are we agree to apply RFComments 30: http://wiki.orfeo-toolbox.org/index.php/Request_for_Comments-30:_Shorter_release_process ?
[14:21] <grizonnetm> It was not clear for me
[14:21] <jmichel> For me we do not need RC
[14:21] <jmichel> RC is the new X.Y branch
[14:22] <jmichel> you can test it whenever you want, based on nightly packages
[14:22] <grizonnetm> as the framapad does not follow completely orientations of RFC 30: https://framacalc.org/v5CYYNhDXP
[14:22] <jmichel> agree
[14:23] <guillaume__> Release actions needs an update
[14:23] <grizonnetm> ok in this case we should promote the rfcomments to an rfc and then update the "how to release"
[14:24] <jmichel> ok lets do this
[14:24] <jmichel> maybe the release manager role is not clear enough
[14:24] <guillaume__> +1
[14:24] <jmichel> I mean I did the git checkout -b 5.6 and then that was it for me
[14:24] <jmichel> what happens next ?
[14:24] <jmichel> That is where we loose some time
[14:25] <jmichel> should the release manager be responsible for tracking actions in the pad ?
[14:25] <grizonnetm> i think so
[14:25] <jmichel> ok that needs to be clarified
[14:26] <guillaume__> We often have cases were issues are spotted during release process. The release manager should say if this is blocking or not
[14:26] <jmichel> yes ok
[14:26] <grizonnetm> update in "how to release" are I think very limited
[14:26] <jmichel> someone has to decide
[14:27] <jmichel> same thing for minor release
[14:27] <jmichel> when is a minor release required ?
[14:28] <grizonnetm> I see it as an "on demand" release which adress critical issues, regressions, important documentation or compiler support...
[14:29] <grizonnetm> difficult to have clear rules to decide when we need a bugfix release
[14:30] <jmichel> ok but who decides ?
[14:31] <guillaume__> release manager ?
[14:32] <grizonnetm> PSC?
[14:32] <grizonnetm> I don't know
[14:32] <jmichel> I think RM should be responsible for the release from start to end
[14:33] <guillaume__> +1
[14:33] <grizonnetm> +1
[14:34] <grizonnetm> let's add this to RFC 30
[14:35] == cresson [~cresson@mtd201.teledetection.fr] has joined #otb
[14:35] == cresson_ [c130bdc9@gateway/web/freenode/ip.193.48.189.201] has joined #otb
[14:35] == cresson_ [c130bdc9@gateway/web/freenode/ip.193.48.189.201] has quit [Client Quit]
[14:36] <cresson> hello
[14:36] <grizonnetm> hi
[14:36] <guillaume__> hi
[14:37] <jmichel> good
[14:37] <jmichel> hi remi
[14:37] <cresson> my apologies for the delay, lot of people at the restaurant
[14:39] <grizonnetm> ok
[14:40] <grizonnetm> so we're discussing adjustements to the release process
[14:41] <jmichel> we decided to extend a bit the role of release manager to :
[14:41] <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:42] <cresson> ok
[14:43] <cresson> what is exaclty new for the RM
[14:44] <jmichel> and also RM will track actions from branching to final release, and decide when to do minor releases
[14:44] <jmichel> ok
[14:45] <grizonnetm> other feedback from release 5.6?
[14:46] <jmichel> a great deal of RFC
[14:48] <jmichel> anything else ?
[14:49] <jmichel> or can we move on ?
[14:49] <cresson> Yes we can !
[14:49] <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:49] <guillaume__> ok
[14:49] <grizonnetm> I think it's missing
[14:49] <grizonnetm> I've started a discussion on otb-dev about this
[14:49] <grizonnetm> 2 weeks ago
[14:49] <jmichel> good point. No more nice charts for slides since we moved out of sourceforge
[14:50] <jmichel> I think we have the data somewhere in server supervisor
[14:50] <jmichel> If OTB was an android app, we could get a lot of info on our users )
[14:50] <jmichel> ;)
[14:51] <grizonnetm> ITK is still using sourceforge
[14:51] <guillaume__> I thought we had some monitoring on the website
[14:52] <grizonnetm> PSC members at minimum should be able to find this information somewhere
[14:53] <jmichel> agree
[14:54] <cresson> agree too
[14:54] <jmichel> we need to see this with sebastien
[14:54] <grizonnetm> ok
[14:54] <grizonnetm> I add this to the wiki
[14:54] <grizonnetm> next?
[14:55] <jmichel> OpenJPEG ?
[14:55] <grizonnetm> ok
[14:55] <grizonnetm> Decision about removal of internal OpenJPEG reader in OTB
[14:56] <jmichel> +1
[14:56] <jmichel> next ;)
[14:57] <jmichel> this is confusing for users
[14:57] <grizonnetm> :)
[14:57] <jmichel> plus find openjpeg is buggy
[14:57] <guillaume__> +1
[14:58] <grizonnetm> ok so we need an RFC to make the code deprecated in 5.8
[14:59] <jmichel> do we ?
[15:00] <jmichel> is someone calling JPEG2000ImageIO directly ?
[15:00] <grizonnetm> i don't think so
[15:02] <jmichel> ok
[15:02] <jmichel> maybe we can remove it directly
[15:02] <jmichel> I do not mind to mark it deprecated first, but I would like to be sure it gets removed someday ;)
[15:03] <jmichel> Side proposal : deprecated class can only be deprecated for one release. After that, either they get remove or undeprecated
[15:04] <guillaume__> This is something we can add in the how-to-release ...
[15:04] <guillaume__> direct removal or deprecated are both fine for me
[15:05] <grizonnetm> I think that currently there are only classes in SVMLearning which are deprecated in OTB
[15:05] <grizonnetm> but they are here for a long time that's true
[15:06] <grizonnetm> direct removal also fine for me
[15:06] <grizonnetm> next topic?
[15:07] <grizonnetm> Dashboard scripts following Monteverdi integration
[15:07] <grizonnetm> Guillaume?
[15:07] <guillaume__> I wanted to discuss this point only because Monteverdi will soon be integrated
[15:08] <guillaume__> and it would be the right moment to apply some refactoring on the dashboard scripts,
[15:08] <guillaume__> there was an RFComment in that way
[15:09] <guillaume__> http://wiki.orfeo-toolbox.org/index.php/Request_for_Comments-18:_Factorize_CMake_configuration
[15:10] <jmichel> why not
[15:10] <jmichel> but this sounds like a lot of work
[15:10] <guillaume__> it depends on the final objectives
[15:11] <guillaume__> we could start to standardize things between different platforms
[15:11] <guillaume__> for me, the benefit would be to have simpler scripts.
[15:12] <jmichel> ok
[15:13] <jmichel> others, do you have an opinion on this ?
[15:13] <cresson> not reall
[15:14] <cresson> y
[15:14] <guillaume__> Victor should have an opinion since he wrote the RFC
[15:14] <grizonnetm> not really also
[15:15] <grizonnetm> agree that ITK got simpler scripts: https://open.cdash.org/viewNotes.php?buildid=4534145
[15:16] <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:17] <grizonnetm> I agree however on the fact that Config in OTB-DevUtils is really messy
[15:17] <grizonnetm> with lots of old platforms and scripts that can be removed
[15:17] <guillaume__> +1 for cleaning
[15:18] <rkm_> i did some work on adding scripts for windows and travis which was interersting
[15:18] <rkm_> the idea was to force "xdk" and a single dashboard cmake file dashboard.cmake
[15:18] <rkm_> with two launcher scripts
[15:19] <rkm_> dashboard.sh and dashboard.bat
[15:19] <rkm_> and that was end of my configuraiton. infact dashboard.bat i used in two windows without a less mess ups!
[15:21] <grizonnetm> so let's restart the discussion on otb-developers about this (difficult to discuss here without Victor who wrote the RFC IMHO)
[15:21] <jmichel> +1 for cleaning there are so much files in OTB-DevUtils/Config
[15:21] <jmichel> Victor is arriving
[15:21] == VictorPoughon [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has joined #otb
[15:21] <jmichel> tadaaa
[15:22] <cresson> hi Victor
[15:22] <VictorPoughon> hi everyone
[15:23] <guillaume__> hi Victor, we were talking about Dashboard script factorization