IRC log of Friday 2016.04.15 14:00 CEST

From OTBWiki
Jump to: navigation, search

[13:51] <jmichel> hi all
[13:51] <jmichel> does anybody know how to become op of an irc channel here ?
[13:57] == gpasero [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[13:57] <gpasero> hello !
[13:58] <grizonnetm> up and ready
[14:00] == inglada [~user@pc-117-162.ups-tlse.fr] has joined #otb
[14:02] <VictorPoughon> hi everyone !
[14:02] <jmichel> hi
[14:02] <jmichel> someone has news from Remi ?
[14:02] <inglada> hello
[14:04] <grizonnetm> I'll try to call him right now
[14:07] <grizonnetm> I can't reach him for now
[14:07] <grizonnetm> think we can start
[14:08] <grizonnetm> english? french?
[14:08] <VictorPoughon> come on, we are so good at english
[14:08] <inglada> the logs are public
[14:08] <jmichel> logs published on wiki, so this will be an english conversation between french (always a lot of fun)
[14:08] <gpasero> ok
[14:09] <jmichel> shall we start ?
[14:09] <inglada> oui
[14:09] == rashadkm [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:09] <grizonnetm> Да
[14:09] <VictorPoughon> I can do the agenda if that's ok
[14:09] <grizonnetm> please
[14:10] <VictorPoughon> FYI the agenda is here: http://wiki.orfeo-toolbox.org/index.php/PSC_meetings#Agenda_3
[14:10] <VictorPoughon> Let's start with 1. Feedback on 5.4 release experience
[14:10] <jmichel> any comments ?
[14:10] <VictorPoughon> Well it's not released yet
[14:11] <VictorPoughon> But I'm looking forward to the RC because a lot of bugs have been fixed
[14:11] <jmichel> we've achieved 12 RFCs which is not bad at all in 3 months
[14:12] <grizonnetm> we should avoid next time to have to switch configuration on dash from develop to release-X.X branch
[14:12] <jmichel> but IMHO we need to improve again the steps after creating release branch
[14:12] <jmichel> exactly
[14:13] <jmichel> aside from bug-fixing, everything should run automatically
[14:13] <grizonnetm> platforms should test in parallel develop and release branches
[14:13] <gpasero> meaning : more dashboards ?
[14:13] <jmichel> more automation I think
[14:13] <grizonnetm> between release I don't think we need much submisionns from the release branch
[14:14] <jmichel> we do not need to test the release branch everyday when not in release phase
[14:14] <jmichel> but activating release build must be a single commit to otb-devutils/Config
[14:14] <jmichel> and anyone should be able to do it
[14:14] <gpasero> currently : it is the case ,
[14:14] <grizonnetm> agree
[14:15] <gpasero> only problem is : our historic servers for dashboard are a bit overloaded
[14:15] <gpasero> we should put more machines
[14:15] <VictorPoughon> There are two things: dashboard and nightly builds (which end up in /packages)
[14:15] <jmichel> gpasero: ok, I assume it is quite fresh, and it needs to be documented
[14:15] <jmichel> gpasero: ok
[14:16] <jmichel> but we can settle this during a dedicated meeting gpasero
[14:16] <grizonnetm> we can perhaps remove Ubuntu14.04-64bits-Release-GDAL_2.0 info submission from hulk and switch to release branch
[14:16] <grizonnetm> looking at ITK
[14:17] <grizonnetm> they've got like 40/50 daily submissions from the master branch
[14:17] <gpasero> as jmichel said, we can work on a better build distribution in a dedicated meeting
[14:17] <grizonnetm> and 2/3 from the release branch
[14:17] <jmichel> only things to act now : we need more automation
[14:18] <jmichel> and we can not release every 3 months if the release process is too long
[14:18] <jmichel> but we already said this
[14:18] <VictorPoughon> ok let's move on?
[14:18] <grizonnetm> k
[14:18] <jmichel> any other feedback on PSC process for the release ?
[14:18] <jmichel> running smoothly from my perspective
[14:18] <gpasero> ok for automation
[14:18] <VictorPoughon> I would like to propose an updated "merge checklist"
[14:18] <VictorPoughon> after 5.4
[14:19] <VictorPoughon> to clarify the wiki a bit
[14:20] <VictorPoughon> my experience as RM was ok
[14:20] == cresson [~cresson@mtd201.teledetection.fr] has joined #otb
[14:20] <cresson> Hi
[14:20] <jmichel> hi cresson
[14:21] <cresson> sorry for this delay
[14:21] <grizonnetm> hi
[14:21] <gpasero> hi
[14:21] <VictorPoughon> hi
[14:21] <VictorPoughon> this section on the wiki http://wiki.orfeo-toolbox.org/index.php/Release_planning#Feature_branch_merge_acceptance_checklist
[14:21] <VictorPoughon> could use a clean up
[14:22] <gpasero> what would you remove ?
[14:23] <jmichel> ok, I propose that you update it and discuss it on otb-developers
[14:23] <VictorPoughon> jmichel: yes that was my plan
[14:23] <VictorPoughon> gpasero: minor things really
[14:23] <grizonnetm> ko
[14:23] <grizonnetm> ok
[14:24] <VictorPoughon> ok let's move on
[14:24] <VictorPoughon> === 2. New features for 5.6
[14:24] <jmichel> For a start, we still have work to do on the new sampling/classification framework
[14:25] <inglada> jmichel: yes please
[14:25] <jmichel> planned
[14:25] <jmichel> (and undergoing)
[14:25] <inglada> I found that splitting the work in several RFCs was a good idea
[14:26] <jmichel> good
[14:26] <inglada> What would be next?
[14:26] <jmichel> I have this S1 model for OSSIM
[14:26] <jmichel> I was under the impression that this was desired by a few users ...
[14:26] <inglada> jmichel: what would be next for resampling?
[14:26] <jmichel> sorry
[14:27] <inglada> i mean sampling and classification, sorry
[14:27] <jmichel> Sample selection filter RFC to be merged
[14:27] <jmichel> almost done
[14:27] <jmichel> then measurement filter (takes sample position and generates sample values)
[14:27] <gpasero> most of the remaining work is the integration into existing app
[14:27] <jmichel> then create new training apps to process those sample
[14:28] <inglada> is this possible for next releas?
[14:28] <jmichel> and finaly revamp existing app to use new framework while preserving apps API as gpasero said
[14:28] <jmichel> maybe not everything
[14:28] <jmichel> but we can for sure make a big step forward
[14:29] <VictorPoughon> any other wishes for 5.6?
[14:29] <inglada> I mean, would it be interesting to give this a higher priority?
[14:29] <jmichel> inglada, it has been almost our sole priority already
[14:29] <inglada> OK
[14:30] <gpasero> I think we've done more than 50% of this story
[14:30] <jmichel> but yes I think this is the biggest fish for next release
[14:31] <jmichel> inglada: is there people at your lab that could be early adopter of this
[14:31] <inglada> jmichel: oh yes
[14:31] <jmichel> so that it could be tested by real users ?
[14:32] <jmichel> (real users = not developers)
[14:32] <inglada> if real users is like processing whole France with 1 year of S2 data, yes
[14:32] <jmichel> ok good
[14:32] <cresson> I think so too
[14:32] <gpasero> ...
[14:32] <inglada> but it would not be like "external users"
[14:33] <VictorPoughon> users are users
[14:33] <jmichel> I think that we really need those early test to get it right fast
[14:33] <jmichel> the more the better
[14:33] <jmichel> ok
[14:33] <inglada> we can have someone to make tests and compare with our current home made python/ogr+bacl magic recipe
[14:34] <jmichel> good
[14:34] <jmichel> so that is settled
[14:34] <jmichel> what about S1 ?
[14:34] <inglada> thank you
[14:34] <inglada> you said S1 ortho?
[14:34] <jmichel> yes
[14:34] <jmichel> well, I said S1 sensor modelling ;)
[14:34] <inglada> same answer but r/S2/S1
[14:35] <jmichel> I have the ossim code I wrote : generic implementation of SAR modelling, S1 and TSX implementation (thanks to grizonnetm for TSX)
[14:35] <inglada> jmichel: can you outline what's left to do?
[14:35] <jmichel> First, I gave it to Luc for a code review
[14:36] <inglada> brave guy
[14:36] <inglada> ;)
[14:36] <jmichel> what is left :
[14:36] <jmichel> merge my S1 model with the current S1 model in ossimplugins (which handles parameter for radiometric calibration)
[14:37] <jmichel> handle read/write of necessary geometric parameters to geom files
[14:37] <jmichel> option: do the same for TSX
[14:38] <jmichel> gold option : do the same for every other sensors and remove the old SAR geometric modelling implementation
[14:38] <inglada> these are 4 RFCs
[14:39] <jmichel> yes
[14:39] <jmichel> maybe we can achieve 1 or 2 for 5.6
[14:39] <jmichel> for sure not the 4 with sampling being the priority
[14:39] <inglada> that would be great
[14:39] <VictorPoughon> anything else for 5.6?
[14:40] <inglada> we have started to have a look at Shark integration
[14:40] <inglada> there are 2 delicate issues which may be solved if someone with more experience has a look at it
[14:41] <inglada> we are a bit stuck
[14:41] <grizonnetm> about what?
[14:41] <VictorPoughon> inglada: you should publish your thoughts so far and why your are stuck
[14:42] <inglada> 1. conflicts between pthreads (itk) and OpenMP (shark)
[14:42] <jmichel> if someone was able to help you, would be available to do the remaining of the RFC on your side
[14:42] <jmichel> ?
[14:42] <inglada> 2. shark uses batches of data and otb uses single samples
[14:43] <cresson> batches of data?
[14:43] <jmichel> For 1. I do not know, but 2. could be solved by evolving MachineLearningModel class
[14:43] <inglada> sets of samples for efficiency (memory locality)
[14:43] <inglada> I can do a RFComments and then discuss what can be done
[14:43] <jmichel> ok
[14:44] <gpasero> maybe Luc could help on 1
[14:44] <jmichel> Last thing I think we should move forward is the MPI implementation
[14:44] <jmichel> gpasero: sure
[14:45] <jmichel> but I do not think that CS team can handle those two additional issues on their own for 5.6
[14:45] <jmichel> but they can provide help for sure
[14:45] <inglada> for shark, it can be either very simple or take more time, I am not sure
[14:46] <inglada> so RFComments and then we'll see
[14:46] <jmichel> ok, RFComments is the way
[14:46] <VictorPoughon> (MPI is on the agenda for later)
[14:46] <jmichel> guys, I am starting to see some roadmap beyond the scope of a single release here
[14:46] <jmichel> MPI, Shark, SAR modelling, Classification framework
[14:47] <jmichel> it is not very long term, but more than a release
[14:47] <cresson> => OTB 6
[14:47] <jmichel> maybe we should write those directions somewhere ?
[14:47] <grizonnetm> yes
[14:47] <VictorPoughon> nice transition to the next item on the agenda
[14:47] <grizonnetm> roadmap was on the agenda
[14:47] <VictorPoughon> === 3. Where is the "OTB wishlist". i.e. features not currently being worked on and without a technical proposal? (wiki, jira, .txt file somewhere...)
[14:47] <grizonnetm> https://git.orfeo-toolbox.org/otb-documents.git/blob/HEAD:/PSC/roadmaps.org
[14:48] <jmichel> the way I see it, there are :
[14:48] <VictorPoughon> I wrote this item because we currently have: grizonnetm's above link, a very aging jira backlog, emails on otb-developers, ...
[14:48] <grizonnetm> jordi's initiative last year to organize otb whishlist
[14:48] <jmichel> 1) things we are working on -> RFC
[14:48] <jmichel> 2) the List of everything we would be interested in doing -< roadmaps.org
[14:49] <jmichel> 3) Our plans for near future -> ?
[14:50] <gpasero> in my mind : 3) would be the roadmap, 2) would be a shopping cart with all the ideas
[14:51] <gpasero> anyway, for 3) we could have a wiki section, near the PSC decisions
[14:51] <jmichel> inglada, as the collector of 2), what do you think ?
[14:52] <grizonnetm> I can try to update roadmaps.org for next otb users day
[14:52] <grizonnetm> but agree that we need something else to collect our plans for near future
[14:53] <inglada> I think that the top down approach (that I proposed) is wrong
[14:53] <inglada> we see that needs and opportunities arise as we go (MPI, Shark, etc.)
[14:53] <inglada> and these define the real work which is done
[14:53] <VictorPoughon> a time based approach?
[14:54] <jmichel> a roadmap should have milestones
[14:54] <inglada> No; I think that ideas come, we discuss, we estimate the effort vs impact and then we go
[14:54] <jmichel> inglada: I agree
[14:55] <inglada> if the idea is to much work, we split into multiple RFCs and that seems to work fine
[14:55] <jmichel> but we go for plans that outpass a single release
[14:56] <inglada> jmichel: yes, we have a limited size bucket (release) and we fill it
[14:56] <jmichel> so the question is : if I am a visitor to the project, where do I find those plans ?
[14:56] <VictorPoughon> Should we make a "Roadmap" wiki page with sections for each future release (5.6, 5.8,... 6.0..., later, ...)?
[14:56] <inglada> why do you need such plans?
[14:56] <jmichel> maybe we don't
[14:57] <jmichel> but say someone finds the sample selection RFC
[14:57] <jmichel> how does he know that this is part of a bigger picture that will be implemented in next releases ?
[14:57] <jmichel> s/he/she/
[14:57] <inglada> Do ourselves really know?
[14:57] <gpasero> hope so
[14:58] <jmichel> well it depends ;)
[14:58] <gpasero> long-term planning would be a nice addition to the project's image
[14:59] <jmichel> so we do not need a roadmap, maybe we need a hot topics section instead ;)
[14:59] <VictorPoughon> roadmaps.org is not really "long term planning" more of a brain dump, no?
[14:59] <gpasero> +1
[14:59] <VictorPoughon> (it's good to have both)
[14:59] <inglada> Given the fact that we do not depend on a single stakeholder (funding, project, customer) who knows were we'll lead
[15:00] <VictorPoughon> where no one has gone before
[15:00] <jmichel> maybe you are right
[15:00] <inglada> I think that a general mission statement + a structured whish list (without commitment) is a good trade-off
[15:01] <grizonnetm> think that it could be useful if subjects we discuss above "MPI, Shark, SAR modelling, Classification framework" can be somewhere on the wiki
[15:01] <inglada> grizonnetm: agreed
[15:01] <jmichel> RFCo should be used for this
[15:02] <jmichel> Maybe we just need to sort and organize RFCo better
[15:02] <grizonnetm> yes we need
[15:02] <inglada> Maybe a section on otbs web site with a link to the RFCs wiki page saying: "this is what we are planning" is OK
[15:02] <jmichel> + jordi stuff about statement and whishlist
[15:02] <gpasero> It will be difficult to advertise RFCo as such,
[15:02] <gpasero> +1 for a "coming next " section on the website
[15:03] <gpasero> ... that will point back to wiki
[15:03] <inglada> Maintaining a curated RFC may need some work
[15:03] <VictorPoughon> ok I also want to ask the PSC two questions:
[15:03] <grizonnetm> sort implemented RFCo perhaps
[15:04] <VictorPoughon> 1. what do we do with our 2 or 3 year old Jira issues which polute the backlog?
[15:04] <jmichel> rm
[15:04] <gpasero> mv * /dev/null
[15:04] <VictorPoughon> don't some contain useful information?
[15:04] <inglada> gpasero: implemened RFC is the past, not the future
[15:05] <jmichel> we can tag them and hide them
[15:05] <jmichel> maybe
[15:05] <jmichel> same question about bugs if you ask me ;)
[15:06] <gpasero> inglada: RFCo on-going discussions are the future
[15:06] <jmichel> we could : make a list of issues that are older than a year, make a quick review, keep what is useful and remove the remaining (applies both to bugs and jira)
[15:06] <grizonnetm> jordi have already listed some jira tasks in roadmaps.org
[15:06] <jmichel> yes, so that is captured
[15:07] <inglada> I think I took eveything which corresponded to feature requests
[15:07] <VictorPoughon> ... and forgotten
[15:07] <inglada> only more recent ones are missing
[15:07] <grizonnetm> could do this clean up during next code sprint in June
[15:07] <VictorPoughon> besides, is Jira for work planning between cnes and cs teams or not?
[15:08] <VictorPoughon> I mean only for that, or more?
[15:08] <grizonnetm> mapserver team has done this kind of bug sorting during last osgeo code sprint in Patis
[15:08] <grizonnetm> Paris
[15:08] <jmichel> In the current state, Jira is the corpus of work between cnes and cs
[15:09] <jmichel> I do not see anyone else logging and using it
[15:09] <jmichel> But if other team working on OTB regularly need a planning tool, they are welcome to use it
[15:10] <VictorPoughon> ok so action: close every jira issue not currently being worked on (or in immediate future)
[15:10] <VictorPoughon> ?
[15:10] <jmichel> Can we plan this for the hackaton as Manuel suggested ?
[15:10] <VictorPoughon> ...and move it to either roadmaps.org or wiki/website "coming next" page
[15:11] <VictorPoughon> ... depending on maturity level
[15:11] <VictorPoughon> which in order of least to most mature is: roadmaps.org, "coming next" page, RFcomments ?
[15:11] <grizonnetm> ok for me, could be our first task for Victor and I in June
[15:12] <gpasero> there is also mantis cleaning (for June ?)
[15:12] <grizonnetm> yes
[15:13] <gpasero> +1 for Jira cleaning
[15:13] <jmichel> ok, I think we are not going anywhere further on this roadmap thing today (and that's ironic), can we move on and let this topic work itself inside our brains during sleep ?
[15:13] <grizonnetm> agree
[15:13] <gpasero> yes
[15:13] <inglada> zzzzz
[15:13] <VictorPoughon> ok moving on
[15:13] <VictorPoughon> === 4. What is our packaging strategy ?
[15:13] <inglada> tar
[15:14] <jmichel> I mean, things are functionning, it is not like we need something right now
[15:14] <jmichel> I think we should clarify this
[15:14] <jmichel> in its current state it is a mess of different packages of different (sometimes quite old) versions of OTB made on a irregular basis by different people
[15:15] <grizonnetm> the bazaar!
[15:15] <jmichel> so if I am a user, I do not know what OTB I will get from say brew, or CentOS, and if it will be complete or even work well
[15:16] <VictorPoughon> first of all, cnes is responsible for standalone packaging during release process, correct?
[15:16] <jmichel> Yes
[15:16] <jmichel> we are working on a mac standalone package so we will have the 3 major OS
[15:16] <jmichel> and we will do it everytime, for each release
[15:16] <inglada> isn't that enough?
[15:16] <VictorPoughon> ok then
[15:16] <VictorPoughon> externel packaging is left as an exercise to the community
[15:17] <VictorPoughon> ?
[15:17] <VictorPoughon> grizonnetm: what was your experience as packaging manager?
[15:17] <grizonnetm> ...
[15:17] <jmichel> inglada: for releases that is enough ( and that is what we decided during last psc meeting)
[15:18] <jmichel> So the download page of OTB should reflect this
[15:18] <inglada> jmichel: in that case, I don't understand the problem, sorry
[15:18] <gpasero> if so, we should add a disclaimer about non-standalone packages
[15:18] <grizonnetm> that's true that we've lost some platform supprot after moving to external itk,ossim with otb 5.0
[15:18] <jmichel> inglada: problem is we have a pile of issues on distributions
[15:19] <VictorPoughon> inglada: one problem is that once a package is made, it is out in the wild forever
[15:19] <grizonnetm> especially Mac OS X
[15:19] <jmichel> ubuntugis packages are missing libsvm, osgeo4w does not build anymore, brew package installs fltk (because it is old)
[15:19] <inglada> jmichel: but "OTB only provides standalone packages and can not give support on community built packages"
[15:19] <jmichel> we could say that
[15:20] <VictorPoughon> inglada: sadly that will not stop users from installing from ubuntu gis and complaining about bugs
[15:20] <jmichel> but ultimately, when a user installs a broken packages he thinks that the software does not work, not the distribution
[15:20] <inglada> we don't have the ressources to do otherwise, I guess
[15:20] <grizonnetm> see calibre for instance
[15:20] <grizonnetm> https://calibre-ebook.com/download_linux
[15:20] <grizonnetm> "Please do not use your distribution provided calibre package, as those are often buggy/outdated. Instead use the Binary install described below. "
[15:20] <inglada> response to these bug reports: will not fix - install the standalone package
[15:21] <inglada> grizonnetm: agreed
[15:21] <gpasero> the project should maybe try to gather more external contributors for this packaging
[15:21] <jmichel> ok why not
[15:21] <VictorPoughon> maybe add a warning on the website "Downloads" page like gpasero said + a summary table by distribution
[15:21] <inglada> let's put the effort on the content, not the packaging ;)
[15:22] <jmichel> but in this case standalone packages should be usable for development, as OTB is a library (remember? ;))
[15:22] <gpasero> inglada : packaging is crucial
[15:22] <VictorPoughon> inglada: the number of users is a parameter to otb's global utility function
[15:23] <inglada> as far as I remember, linux packaging was meant to overcome the non existence of a standalone binary,
[15:23] <inglada> maybe we can have a binary + dev package which allows using the lib
[15:23] <rashadkm> for development , i mean *-dev packages can be replaced with our own sdk
[15:23] <VictorPoughon> inglada: that is indeed on the roadmap
[15:23] <inglada> do we have a roadmap?
[15:24] <gpasero> :)
[15:24] <rashadkm> xdk exists for windows and linux now.
[15:24] <jmichel> ok but I am sad to abandon support to debiangis ...
[15:24] <gpasero> OTB standalone xdk exists
[15:24] <jmichel> after all those efforts ...
[15:24] <inglada> rashadkm: please do not link the distribution to specific tools
[15:24] <grizonnetm> efforts done in last December...
[15:24] <gpasero> +1 for debiangis
[15:25] <rashadkm> jmichel: agreed. we are so close... 5.2.1 is there in debian ftp master
[15:25] <rashadkm> inglada: what specific tools ?
[15:25] <VictorPoughon> +1 for debiangis also
[15:25] <cresson> yes +1
[15:25] <VictorPoughon> ok, ready to move on to 5. Technical topics?
[15:26] <inglada> rashadkm: I think I don't know what xdk you mean
[15:27] <rashadkm> xdk = external development kit. this include all headers + .lib or .so needed by OTB to compile without anything else on system.
[15:27] <rashadkm> expect a compiler and cmake .
[15:27] <inglada> rashadkm: OK, in this case I agree and issue solved
[15:28] <jmichel> VictorPoughon: 1 sec, we are almost done
[15:28] <jmichel> so cnes/cs team supports standalone and debiangis
[15:28] <VictorPoughon> (jmichel: of course)
[15:28] <jmichel> maybe other from the community want to support other distribs
[15:28] <grizonnetm> BTW Angelos is maintaining OpenSUSE package for years now without problem
[15:29] <jmichel> everything else is unsupported and advertised as such on the wiki
[15:29] <cresson> Is there some doc on the wiki about packaging ?
[15:29] <gpasero> +1
[15:29] <inglada> jmichel: seems reasonable
[15:29] <VictorPoughon> cresson: http://wiki.orfeo-toolbox.org/index.php/Binary_packages_status
[15:29] <jmichel> meaning : you can install those packages but we do not know if they will work and we will not fix them
[15:29] <inglada> jmichel: +1
[15:29] <jmichel> perfect
[15:30] <cresson> I mean it could be great to give the recipe to produce the package
[15:30] <gpasero> I would also add the warning from Calibre about building from source ... nice one!
[15:30] <cresson> in order to make possible contributions from the community
[15:30] <VictorPoughon> gpasero: a bit extreme but true :)
[15:31] <jmichel> pfff, I was planning to propose gentoo packages ...
[15:31] <inglada> gpasero: we have the superbuild
[15:31] <jmichel> cresson: everything we have is in otb-devutils
[15:31] <gpasero> inglada: true !
[15:31] <inglada> and it works very well http://jordiinglada.net/wp/2015/05/27/installing-otb-has-never-been-so-easy-8/
[15:31] <cresson> ok
[15:32] <jmichel> but of course if there is someone that volunteers to make new package we will help
[15:32] <cresson> we use to have somebody involved in this
[15:33] <cresson> could be great to take back the job
[15:33] <jmichel> ok
[15:33] <jmichel> so we only need to update the wiki in order to display and enforce this packaging policy
[15:33] <inglada> not only the wiki, but also the download page
[15:33] <jmichel> yes inglada
[15:34] <jmichel> packaging manager ? or victor as release manager ?
[15:34] <VictorPoughon> I can take that action as part of release process
[15:34] <jmichel> ok sold
[15:34] <jmichel> next ?
[15:34] <VictorPoughon> === 5.1 Should Monteverdi be merged into OTB?
[15:35] <inglada> yes, next
[15:35] <jmichel> +1
[15:35] <grizonnetm> +++++1
[15:35] <VictorPoughon> ok waiting for RFco
[15:35] <inglada> ++++++++++++10
[15:35] <VictorPoughon> === 5.2 Simple OTB
[15:35] <gpasero> why not
[15:35] <jmichel> not much to say about it
[15:35] <inglada> oxymoron
[15:35] <jmichel> just that we are often asked about programming with otb in python
[15:36] <jmichel> and we are left with the app API, which is not really programming with otb in python
[15:36] <grizonnetm> cp -r SimpleITK SimpleOTB
[15:36] <jmichel> I will read the extended paper on SimpleITK, and come back with a RFCo describing what I think we could do
[15:36] <inglada> who is going to use and maintain that? which support?
[15:36] <jmichel> inglada, that is the problem
[15:37] <inglada> this is why the first OTB bindings died
[15:37] <jmichel> it is yet a new thing to maintain and package
[15:37] <gpasero> I fear it will add a lot of work for maintainance
[15:37] <VictorPoughon> besides, isn't there room for improvement in our current python bindings?
[15:37] <jmichel> I was hoping that it would be less complex than the cmake/cable-swig/gcc-xml nightmare of bindings
[15:38] <jmichel> but first looks at the code is frigthening ;)
[15:38] <gpasero> VictorPoughon: +1 for this easy way
[15:38] <jmichel> ok
[15:38] <jmichel> I will have a look
[15:38] <jmichel> and come back to you
[15:39] <VictorPoughon> ok so no PSC decision today, RFco are welcome as usual?
[15:39] <inglada> I have to go, sorry
[15:39] <jmichel> lets talk about MPI
[15:39] <VictorPoughon> === 5.3 JPEG2000 and Sentinel2 products
[15:39] <jmichel> ok inglada
[15:39] <VictorPoughon> (mpi is next)
[15:41] <jmichel> ok
[15:41] <jmichel> just to say that we have a gdal driver for S2
[15:41] <gpasero> what is the issue with JP2K & Sentinel ?
[15:41] <jmichel> but it uses the jpeg2000 driver to read the products
[15:41] <jmichel> and openjpeg driver is painly slow
[15:41] <jmichel> so in the end, it is almost not usable (especially for visu)
[15:42] <jmichel> we now have users that try to open S2 products in Monteverdi
[15:42] <jmichel> and give up
[15:42] <VictorPoughon> Call ESA?
[15:43] <jmichel> there is a version of openjpeg that is supposed to be super fast
[15:43] <jmichel> a fork
[15:43] <jmichel> I think we need to try this
[15:43] == inglada [~user@pc-117-162.ups-tlse.fr] has quit [Ping timeout: 244 seconds]
[15:43] <cresson> fast, but with approximations?
[15:44] <jmichel> I do not really know
[15:44] <VictorPoughon> Link to fork announcement: https://groups.google.com/forum/#!topic/openjpeg/F6IJ9ROz7Zg
[15:44] <grizonnetm> https://github.com/GrokImageCompression/grok
[15:44] <VictorPoughon> C++14, AGPL License
[15:44] <VictorPoughon> quote: "currently it is roughly 1/3 the perf of Kakadu, (tested on windows), and I am hoping to get it down to around 1/2"
[15:45] <gpasero> What actions on this : try to have it as a GDAL driver ?
[15:45] <jmichel> this is not really an OTB issue
[15:45] <jmichel> but if we could try to have grok as a gdal driver in superbuild (and standalone binaries), it would be great
[15:46] <jmichel> at least we need to try it
[15:46] <VictorPoughon> add it to the roadmap :)
[15:47] <VictorPoughon> === 5.4 MPI
[15:47] <grizonnetm> would be interesting to ask to snap developers their feedback about openjpeg for S2
[15:48] <jmichel> grizonnetm: good idea
[15:49] <jmichel> so, MPI
[15:49] <grizonnetm> Guillaume? Can you ask to jmalik?
[15:49] <cresson> to bring MPI in OTB we might need to re-think app wrapping
[15:49] <jmichel> I was hoping that our colleague emmanuel could join us
[15:49] <gpasero> yes, he just said that OpenJpeg is clearly slower than kakadu
[15:50] <grizonnetm> ok
[15:50] <grizonnetm> move to MPI
[15:50] <gpasero> but for him, it would be also an option to add contribution to OpenJPEG
[15:50] <gpasero> (ok, move to MPI)
[15:50] <jmichel> did he have a look at the fork ?
[15:51] <cresson> this one needs to be tested on true cluster
[15:51] <gpasero> jmichel: no, he didn't
[15:51] <cresson> :(
[15:51] <jmichel> cresson: I worked a bit with emmanuel on this topic
[15:51] <cresson> we have time
[15:51] <jmichel> +lle
[15:51] <cresson> yes
[15:52] <cresson> some time ago
[15:52] <jmichel> we also have a simpler solution
[15:52] <cresson> yes?
[15:52] <jmichel> involving extract+writer in the MPI block, and vrt file generation
[15:52] <jmichel> pros: it is very simple
[15:52] <cresson> vrt file generation is nice because we use GDAL directly
[15:52] <cresson> agree
[15:53] <jmichel> you can write WriteMPI(reader->GetOutput(),argv[2],MPIRank,MPISize); instead of calling the writer
[15:53] <jmichel> and there you go
[15:53] <cresson> yes
[15:53] <cresson> cons: IO bottleneck might arrive faster (conconrent IO tasks)
[15:54] <jmichel> We had some ideas to better hide the MPI magic by turning this to a class
[15:54] <jmichel> cresson: right
[15:54] <jmichel> this is where the parallel tif is good
[15:54] <cresson> but the output is just a point
[15:55] <cresson> bringing MPI into apps, filters, is important
[15:55] <cresson> your idea?
[15:55] <jmichel> apps could be done with both solutions
[15:55] <jmichel> filters I am not sure. Do you speak of persistent filters ?
[15:55] <cresson> filters wich need some sharing e.g. statistics
[15:55] <jmichel> ok persistent filters
[15:56] <cresson> ok
[15:56] <jmichel> I think we could work something with both solutions
[15:56] <jmichel> persistent filters is just so special filter cabled to a virtual writer
[15:56] <cresson> yes
[15:56] <jmichel> so we could call VirtualWrite(); and it would be soled
[15:56] <jmichel> solved
[15:57] <cresson> I see
[15:57] <cresson> It could be nice to work on this
[15:57] <cresson> however it's far from beeing fully integrated in OTB
[15:57] <grizonnetm> MPI team in June during the hackthon?
[15:57] <cresson> but I think it will be a great new feature
[15:57] <cresson> yes
[15:58] <cresson> could be nice
[15:58] <jmichel> I think we could work something with you and emmanuel for next release
[15:58] <cresson> CNES cluster ? :p
[15:58] <jmichel> but I would be in favour of small steps : first push a simple module that allows to use MPI
[15:58] <jmichel> then try to insert it for apps writing
[15:58] <jmichel> and so on ...
[15:59] <cresson> I agree
[15:59] <jmichel> because we will not get the big picture right in a single shot I think
[16:00] <cresson> It's a good idea to play with otb/mpi at hackton
[16:00] <jmichel> why not
[16:00] <jmichel> bring your own cluster ;)
[16:00] <cresson> ha ha
[16:01] <VictorPoughon> anything else about MPI?
[16:01] <cresson> I started to work on a branch
[16:01] <jmichel> ok
[16:01] <jmichel> maybe we could have a dedicated meeting with you cresson and Emmanuelle
[16:02] <jmichel> or you could come here to work on this together
[16:02] <jmichel> (do not know if its possible for you)
[16:03] <cresson> we can talk about it soom
[16:03] <grizonnetm> next subject?
[16:03] <VictorPoughon> === 6. Next release manager
[16:04] <jmichel> I can do it with a backup
[16:04] <grizonnetm> Jordi?
[16:04] <VictorPoughon> he's not here
[16:05] <grizonnetm> that was the reason why I suggest him :)
[16:05] <grizonnetm> ok I'll do it
[16:05] <gpasero> let's choose a backup to the backup RM in case he says no
[16:05] <jmichel> ok so me and grizonnetm as a backup ?
[16:06] <VictorPoughon> ok so Julien as RM, Jordi as backup RM and grizonnetm as backup backup RM ?
[16:06] <VictorPoughon> PSC member please vote
[16:06] <grizonnetm> I was joking about Jordi
[16:06] <jmichel> +e
[16:06] <gpasero> +1
[16:06] <cresson> +1
[16:06] <grizonnetm> we're good
[16:06] <jmichel> anything else ?
[16:06] <VictorPoughon> ok that's it for the agenda
[16:07] <grizonnetm> Victor can you log the meeting on the wiki?
[16:07] <VictorPoughon> yes
[16:07] <grizonnetm> so have a nice weekend
[16:07] <VictorPoughon> i'll also do a kick write up on the wiki
[16:07] <jmichel> bye everyone
[16:08] <VictorPoughon> thanks all
[16:08] <gpasero> thanks all, bye !
[16:08] <grizonnetm> bye
[16:08] == grizonnetm [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has quit [Quit: Page closed]
[16:08] == gpasero [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has quit [Quit: Page closed]
[16:08] <cresson> bye
[16:10] <cresson> when is the next IRC meeting?
[16:11] <cresson> else, see you in June in real
[16:11] <VictorPoughon> cresson: we thought about doing a "real" meeting for the next one
[16:11] <VictorPoughon> ;)
[16:11] <VictorPoughon> at the user days[13:51] <jmichel> hi all
[13:51] <jmichel> does anybody know how to become op of an irc channel here ?
[13:57] == gpasero [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[13:57] <gpasero> hello !
[13:58] <grizonnetm> up and ready
[14:00] == inglada [~user@pc-117-162.ups-tlse.fr] has joined #otb
[14:02] <VictorPoughon> hi everyone !
[14:02] <jmichel> hi
[14:02] <jmichel> someone has news from Remi ?
[14:02] <inglada> hello
[14:04] <grizonnetm> I'll try to call him right now
[14:07] <grizonnetm> I can't reach him for now
[14:07] <grizonnetm> think we can start
[14:08] <grizonnetm> english? french?
[14:08] <VictorPoughon> come on, we are so good at english
[14:08] <inglada> the logs are public
[14:08] <jmichel> logs published on wiki, so this will be an english conversation between french (always a lot of fun)
[14:08] <gpasero> ok
[14:09] <jmichel> shall we start ?
[14:09] <inglada> oui
[14:09] == rashadkm [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:09] <grizonnetm> Да
[14:09] <VictorPoughon> I can do the agenda if that's ok
[14:09] <grizonnetm> please
[14:10] <VictorPoughon> FYI the agenda is here: http://wiki.orfeo-toolbox.org/index.php/PSC_meetings#Agenda_3
[14:10] <VictorPoughon> Let's start with 1. Feedback on 5.4 release experience
[14:10] <jmichel> any comments ?
[14:10] <VictorPoughon> Well it's not released yet
[14:11] <VictorPoughon> But I'm looking forward to the RC because a lot of bugs have been fixed
[14:11] <jmichel> we've achieved 12 RFCs which is not bad at all in 3 months
[14:12] <grizonnetm> we should avoid next time to have to switch configuration on dash from develop to release-X.X branch
[14:12] <jmichel> but IMHO we need to improve again the steps after creating release branch
[14:12] <jmichel> exactly
[14:13] <jmichel> aside from bug-fixing, everything should run automatically
[14:13] <grizonnetm> platforms should test in parallel develop and release branches
[14:13] <gpasero> meaning : more dashboards ?
[14:13] <jmichel> more automation I think
[14:13] <grizonnetm> between release I don't think we need much submisionns from the release branch
[14:14] <jmichel> we do not need to test the release branch everyday when not in release phase
[14:14] <jmichel> but activating release build must be a single commit to otb-devutils/Config
[14:14] <jmichel> and anyone should be able to do it
[14:14] <gpasero> currently : it is the case ,
[14:14] <grizonnetm> agree
[14:15] <gpasero> only problem is : our historic servers for dashboard are a bit overloaded
[14:15] <gpasero> we should put more machines
[14:15] <VictorPoughon> There are two things: dashboard and nightly builds (which end up in /packages)
[14:15] <jmichel> gpasero: ok, I assume it is quite fresh, and it needs to be documented
[14:15] <jmichel> gpasero: ok
[14:16] <jmichel> but we can settle this during a dedicated meeting gpasero
[14:16] <grizonnetm> we can perhaps remove Ubuntu14.04-64bits-Release-GDAL_2.0 info submission from hulk and switch to release branch
[14:16] <grizonnetm> looking at ITK
[14:17] <grizonnetm> they've got like 40/50 daily submissions from the master branch
[14:17] <gpasero> as jmichel said, we can work on a better build distribution in a dedicated meeting
[14:17] <grizonnetm> and 2/3 from the release branch
[14:17] <jmichel> only things to act now : we need more automation
[14:18] <jmichel> and we can not release every 3 months if the release process is too long
[14:18] <jmichel> but we already said this
[14:18] <VictorPoughon> ok let's move on?
[14:18] <grizonnetm> k
[14:18] <jmichel> any other feedback on PSC process for the release ?
[14:18] <jmichel> running smoothly from my perspective
[14:18] <gpasero> ok for automation
[14:18] <VictorPoughon> I would like to propose an updated "merge checklist"
[14:18] <VictorPoughon> after 5.4
[14:19] <VictorPoughon> to clarify the wiki a bit
[14:20] <VictorPoughon> my experience as RM was ok
[14:20] == cresson [~cresson@mtd201.teledetection.fr] has joined #otb
[14:20] <cresson> Hi
[14:20] <jmichel> hi cresson
[14:21] <cresson> sorry for this delay
[14:21] <grizonnetm> hi
[14:21] <gpasero> hi
[14:21] <VictorPoughon> hi
[14:21] <VictorPoughon> this section on the wiki http://wiki.orfeo-toolbox.org/index.php/Release_planning#Feature_branch_merge_acceptance_checklist
[14:21] <VictorPoughon> could use a clean up
[14:22] <gpasero> what would you remove ?
[14:23] <jmichel> ok, I propose that you update it and discuss it on otb-developers
[14:23] <VictorPoughon> jmichel: yes that was my plan
[14:23] <VictorPoughon> gpasero: minor things really
[14:23] <grizonnetm> ko
[14:23] <grizonnetm> ok
[14:24] <VictorPoughon> ok let's move on
[14:24] <VictorPoughon> === 2. New features for 5.6
[14:24] <jmichel> For a start, we still have work to do on the new sampling/classification framework
[14:25] <inglada> jmichel: yes please
[14:25] <jmichel> planned
[14:25] <jmichel> (and undergoing)
[14:25] <inglada> I found that splitting the work in several RFCs was a good idea
[14:26] <jmichel> good
[14:26] <inglada> What would be next?
[14:26] <jmichel> I have this S1 model for OSSIM
[14:26] <jmichel> I was under the impression that this was desired by a few users ...
[14:26] <inglada> jmichel: what would be next for resampling?
[14:26] <jmichel> sorry
[14:27] <inglada> i mean sampling and classification, sorry
[14:27] <jmichel> Sample selection filter RFC to be merged
[14:27] <jmichel> almost done
[14:27] <jmichel> then measurement filter (takes sample position and generates sample values)
[14:27] <gpasero> most of the remaining work is the integration into existing app
[14:27] <jmichel> then create new training apps to process those sample
[14:28] <inglada> is this possible for next releas?
[14:28] <jmichel> and finaly revamp existing app to use new framework while preserving apps API as gpasero said
[14:28] <jmichel> maybe not everything
[14:28] <jmichel> but we can for sure make a big step forward
[14:29] <VictorPoughon> any other wishes for 5.6?
[14:29] <inglada> I mean, would it be interesting to give this a higher priority?
[14:29] <jmichel> inglada, it has been almost our sole priority already
[14:29] <inglada> OK
[14:30] <gpasero> I think we've done more than 50% of this story
[14:30] <jmichel> but yes I think this is the biggest fish for next release
[14:31] <jmichel> inglada: is there people at your lab that could be early adopter of this
[14:31] <inglada> jmichel: oh yes
[14:31] <jmichel> so that it could be tested by real users ?
[14:32] <jmichel> (real users = not developers)
[14:32] <inglada> if real users is like processing whole France with 1 year of S2 data, yes
[14:32] <jmichel> ok good
[14:32] <cresson> I think so too
[14:32] <gpasero> ...
[14:32] <inglada> but it would not be like "external users"
[14:33] <VictorPoughon> users are users
[14:33] <jmichel> I think that we really need those early test to get it right fast
[14:33] <jmichel> the more the better
[14:33] <jmichel> ok
[14:33] <inglada> we can have someone to make tests and compare with our current home made python/ogr+bacl magic recipe
[14:34] <jmichel> good
[14:34] <jmichel> so that is settled
[14:34] <jmichel> what about S1 ?
[14:34] <inglada> thank you
[14:34] <inglada> you said S1 ortho?
[14:34] <jmichel> yes
[14:34] <jmichel> well, I said S1 sensor modelling ;)
[14:34] <inglada> same answer but r/S2/S1
[14:35] <jmichel> I have the ossim code I wrote : generic implementation of SAR modelling, S1 and TSX implementation (thanks to grizonnetm for TSX)
[14:35] <inglada> jmichel: can you outline what's left to do?
[14:35] <jmichel> First, I gave it to Luc for a code review
[14:36] <inglada> brave guy
[14:36] <inglada> ;)
[14:36] <jmichel> what is left :
[14:36] <jmichel> merge my S1 model with the current S1 model in ossimplugins (which handles parameter for radiometric calibration)
[14:37] <jmichel> handle read/write of necessary geometric parameters to geom files
[14:37] <jmichel> option: do the same for TSX
[14:38] <jmichel> gold option : do the same for every other sensors and remove the old SAR geometric modelling implementation
[14:38] <inglada> these are 4 RFCs
[14:39] <jmichel> yes
[14:39] <jmichel> maybe we can achieve 1 or 2 for 5.6
[14:39] <jmichel> for sure not the 4 with sampling being the priority
[14:39] <inglada> that would be great
[14:39] <VictorPoughon> anything else for 5.6?
[14:40] <inglada> we have started to have a look at Shark integration
[14:40] <inglada> there are 2 delicate issues which may be solved if someone with more experience has a look at it
[14:41] <inglada> we are a bit stuck
[14:41] <grizonnetm> about what?
[14:41] <VictorPoughon> inglada: you should publish your thoughts so far and why your are stuck
[14:42] <inglada> 1. conflicts between pthreads (itk) and OpenMP (shark)
[14:42] <jmichel> if someone was able to help you, would be available to do the remaining of the RFC on your side
[14:42] <jmichel> ?
[14:42] <inglada> 2. shark uses batches of data and otb uses single samples
[14:43] <cresson> batches of data?
[14:43] <jmichel> For 1. I do not know, but 2. could be solved by evolving MachineLearningModel class
[14:43] <inglada> sets of samples for efficiency (memory locality)
[14:43] <inglada> I can do a RFComments and then discuss what can be done
[14:43] <jmichel> ok
[14:44] <gpasero> maybe Luc could help on 1
[14:44] <jmichel> Last thing I think we should move forward is the MPI implementation
[14:44] <jmichel> gpasero: sure
[14:45] <jmichel> but I do not think that CS team can handle those two additional issues on their own for 5.6
[14:45] <jmichel> but they can provide help for sure
[14:45] <inglada> for shark, it can be either very simple or take more time, I am not sure
[14:46] <inglada> so RFComments and then we'll see
[14:46] <jmichel> ok, RFComments is the way
[14:46] <VictorPoughon> (MPI is on the agenda for later)
[14:46] <jmichel> guys, I am starting to see some roadmap beyond the scope of a single release here
[14:46] <jmichel> MPI, Shark, SAR modelling, Classification framework
[14:47] <jmichel> it is not very long term, but more than a release
[14:47] <cresson> => OTB 6
[14:47] <jmichel> maybe we should write those directions somewhere ?
[14:47] <grizonnetm> yes
[14:47] <VictorPoughon> nice transition to the next item on the agenda
[14:47] <grizonnetm> roadmap was on the agenda
[14:47] <VictorPoughon> === 3. Where is the "OTB wishlist". i.e. features not currently being worked on and without a technical proposal? (wiki, jira, .txt file somewhere...)
[14:47] <grizonnetm> https://git.orfeo-toolbox.org/otb-documents.git/blob/HEAD:/PSC/roadmaps.org
[14:48] <jmichel> the way I see it, there are :
[14:48] <VictorPoughon> I wrote this item because we currently have: grizonnetm's above link, a very aging jira backlog, emails on otb-developers, ...
[14:48] <grizonnetm> jordi's initiative last year to organize otb whishlist
[14:48] <jmichel> 1) things we are working on -> RFC
[14:48] <jmichel> 2) the List of everything we would be interested in doing -< roadmaps.org
[14:49] <jmichel> 3) Our plans for near future -> ?
[14:50] <gpasero> in my mind : 3) would be the roadmap, 2) would be a shopping cart with all the ideas
[14:51] <gpasero> anyway, for 3) we could have a wiki section, near the PSC decisions
[14:51] <jmichel> inglada, as the collector of 2), what do you think ?
[14:52] <grizonnetm> I can try to update roadmaps.org for next otb users day
[14:52] <grizonnetm> but agree that we need something else to collect our plans for near future
[14:53] <inglada> I think that the top down approach (that I proposed) is wrong
[14:53] <inglada> we see that needs and opportunities arise as we go (MPI, Shark, etc.)
[14:53] <inglada> and these define the real work which is done
[14:53] <VictorPoughon> a time based approach?
[14:54] <jmichel> a roadmap should have milestones
[14:54] <inglada> No; I think that ideas come, we discuss, we estimate the effort vs impact and then we go
[14:54] <jmichel> inglada: I agree
[14:55] <inglada> if the idea is to much work, we split into multiple RFCs and that seems to work fine
[14:55] <jmichel> but we go for plans that outpass a single release
[14:56] <inglada> jmichel: yes, we have a limited size bucket (release) and we fill it
[14:56] <jmichel> so the question is : if I am a visitor to the project, where do I find those plans ?
[14:56] <VictorPoughon> Should we make a "Roadmap" wiki page with sections for each future release (5.6, 5.8,... 6.0..., later, ...)?
[14:56] <inglada> why do you need such plans?
[14:56] <jmichel> maybe we don't
[14:57] <jmichel> but say someone finds the sample selection RFC
[14:57] <jmichel> how does he know that this is part of a bigger picture that will be implemented in next releases ?
[14:57] <jmichel> s/he/she/
[14:57] <inglada> Do ourselves really know?
[14:57] <gpasero> hope so
[14:58] <jmichel> well it depends ;)
[14:58] <gpasero> long-term planning would be a nice addition to the project's image
[14:59] <jmichel> so we do not need a roadmap, maybe we need a hot topics section instead ;)
[14:59] <VictorPoughon> roadmaps.org is not really "long term planning" more of a brain dump, no?
[14:59] <gpasero> +1
[14:59] <VictorPoughon> (it's good to have both)
[14:59] <inglada> Given the fact that we do not depend on a single stakeholder (funding, project, customer) who knows were we'll lead
[15:00] <VictorPoughon> where no one has gone before
[15:00] <jmichel> maybe you are right
[15:00] <inglada> I think that a general mission statement + a structured whish list (without commitment) is a good trade-off
[15:01] <grizonnetm> think that it could be useful if subjects we discuss above "MPI, Shark, SAR modelling, Classification framework" can be somewhere on the wiki
[15:01] <inglada> grizonnetm: agreed
[15:01] <jmichel> RFCo should be used for this
[15:02] <jmichel> Maybe we just need to sort and organize RFCo better
[15:02] <grizonnetm> yes we need
[15:02] <inglada> Maybe a section on otbs web site with a link to the RFCs wiki page saying: "this is what we are planning" is OK
[15:02] <jmichel> + jordi stuff about statement and whishlist
[15:02] <gpasero> It will be difficult to advertise RFCo as such,
[15:02] <gpasero> +1 for a "coming next " section on the website
[15:03] <gpasero> ... that will point back to wiki
[15:03] <inglada> Maintaining a curated RFC may need some work
[15:03] <VictorPoughon> ok I also want to ask the PSC two questions:
[15:03] <grizonnetm> sort implemented RFCo perhaps
[15:04] <VictorPoughon> 1. what do we do with our 2 or 3 year old Jira issues which polute the backlog?
[15:04] <jmichel> rm
[15:04] <gpasero> mv * /dev/null
[15:04] <VictorPoughon> don't some contain useful information?
[15:04] <inglada> gpasero: implemened RFC is the past, not the future
[15:05] <jmichel> we can tag them and hide them
[15:05] <jmichel> maybe
[15:05] <jmichel> same question about bugs if you ask me ;)
[15:06] <gpasero> inglada: RFCo on-going discussions are the future
[15:06] <jmichel> we could : make a list of issues that are older than a year, make a quick review, keep what is useful and remove the remaining (applies both to bugs and jira)
[15:06] <grizonnetm> jordi have already listed some jira tasks in roadmaps.org
[15:06] <jmichel> yes, so that is captured
[15:07] <inglada> I think I took eveything which corresponded to feature requests
[15:07] <VictorPoughon> ... and forgotten
[15:07] <inglada> only more recent ones are missing
[15:07] <grizonnetm> could do this clean up during next code sprint in June
[15:07] <VictorPoughon> besides, is Jira for work planning between cnes and cs teams or not?
[15:08] <VictorPoughon> I mean only for that, or more?
[15:08] <grizonnetm> mapserver team has done this kind of bug sorting during last osgeo code sprint in Patis
[15:08] <grizonnetm> Paris
[15:08] <jmichel> In the current state, Jira is the corpus of work between cnes and cs
[15:09] <jmichel> I do not see anyone else logging and using it
[15:09] <jmichel> But if other team working on OTB regularly need a planning tool, they are welcome to use it
[15:10] <VictorPoughon> ok so action: close every jira issue not currently being worked on (or in immediate future)
[15:10] <VictorPoughon> ?
[15:10] <jmichel> Can we plan this for the hackaton as Manuel suggested ?
[15:10] <VictorPoughon> ...and move it to either roadmaps.org or wiki/website "coming next" page
[15:11] <VictorPoughon> ... depending on maturity level
[15:11] <VictorPoughon> which in order of least to most mature is: roadmaps.org, "coming next" page, RFcomments ?
[15:11] <grizonnetm> ok for me, could be our first task for Victor and I in June
[15:12] <gpasero> there is also mantis cleaning (for June ?)
[15:12] <grizonnetm> yes
[15:13] <gpasero> +1 for Jira cleaning
[15:13] <jmichel> ok, I think we are not going anywhere further on this roadmap thing today (and that's ironic), can we move on and let this topic work itself inside our brains during sleep ?
[15:13] <grizonnetm> agree
[15:13] <gpasero> yes
[15:13] <inglada> zzzzz
[15:13] <VictorPoughon> ok moving on
[15:13] <VictorPoughon> === 4. What is our packaging strategy ?
[15:13] <inglada> tar
[15:14] <jmichel> I mean, things are functionning, it is not like we need something right now
[15:14] <jmichel> I think we should clarify this
[15:14] <jmichel> in its current state it is a mess of different packages of different (sometimes quite old) versions of OTB made on a irregular basis by different people
[15:15] <grizonnetm> the bazaar!
[15:15] <jmichel> so if I am a user, I do not know what OTB I will get from say brew, or CentOS, and if it will be complete or even work well
[15:16] <VictorPoughon> first of all, cnes is responsible for standalone packaging during release process, correct?
[15:16] <jmichel> Yes
[15:16] <jmichel> we are working on a mac standalone package so we will have the 3 major OS
[15:16] <jmichel> and we will do it everytime, for each release
[15:16] <inglada> isn't that enough?
[15:16] <VictorPoughon> ok then
[15:16] <VictorPoughon> externel packaging is left as an exercise to the community
[15:17] <VictorPoughon> ?
[15:17] <VictorPoughon> grizonnetm: what was your experience as packaging manager?
[15:17] <grizonnetm> ...
[15:17] <jmichel> inglada: for releases that is enough ( and that is what we decided during last psc meeting)
[15:18] <jmichel> So the download page of OTB should reflect this
[15:18] <inglada> jmichel: in that case, I don't understand the problem, sorry
[15:18] <gpasero> if so, we should add a disclaimer about non-standalone packages
[15:18] <grizonnetm> that's true that we've lost some platform supprot after moving to external itk,ossim with otb 5.0
[15:18] <jmichel> inglada: problem is we have a pile of issues on distributions
[15:19] <VictorPoughon> inglada: one problem is that once a package is made, it is out in the wild forever
[15:19] <grizonnetm> especially Mac OS X
[15:19] <jmichel> ubuntugis packages are missing libsvm, osgeo4w does not build anymore, brew package installs fltk (because it is old)
[15:19] <inglada> jmichel: but "OTB only provides standalone packages and can not give support on community built packages"
[15:19] <jmichel> we could say that
[15:20] <VictorPoughon> inglada: sadly that will not stop users from installing from ubuntu gis and complaining about bugs
[15:20] <jmichel> but ultimately, when a user installs a broken packages he thinks that the software does not work, not the distribution
[15:20] <inglada> we don't have the ressources to do otherwise, I guess
[15:20] <grizonnetm> see calibre for instance
[15:20] <grizonnetm> https://calibre-ebook.com/download_linux
[15:20] <grizonnetm> "Please do not use your distribution provided calibre package, as those are often buggy/outdated. Instead use the Binary install described below. "
[15:20] <inglada> response to these bug reports: will not fix - install the standalone package
[15:21] <inglada> grizonnetm: agreed
[15:21] <gpasero> the project should maybe try to gather more external contributors for this packaging
[15:21] <jmichel> ok why not
[15:21] <VictorPoughon> maybe add a warning on the website "Downloads" page like gpasero said + a summary table by distribution
[15:21] <inglada> let's put the effort on the content, not the packaging ;)
[15:22] <jmichel> but in this case standalone packages should be usable for development, as OTB is a library (remember? ;))
[15:22] <gpasero> inglada : packaging is crucial
[15:22] <VictorPoughon> inglada: the number of users is a parameter to otb's global utility function
[15:23] <inglada> as far as I remember, linux packaging was meant to overcome the non existence of a standalone binary,
[15:23] <inglada> maybe we can have a binary + dev package which allows using the lib
[15:23] <rashadkm> for development , i mean *-dev packages can be replaced with our own sdk
[15:23] <VictorPoughon> inglada: that is indeed on the roadmap
[15:23] <inglada> do we have a roadmap?
[15:24] <gpasero> :)
[15:24] <rashadkm> xdk exists for windows and linux now.
[15:24] <jmichel> ok but I am sad to abandon support to debiangis ...
[15:24] <gpasero> OTB standalone xdk exists
[15:24] <jmichel> after all those efforts ...
[15:24] <inglada> rashadkm: please do not link the distribution to specific tools
[15:24] <grizonnetm> efforts done in last December...
[15:24] <gpasero> +1 for debiangis
[15:25] <rashadkm> jmichel: agreed. we are so close... 5.2.1 is there in debian ftp master
[15:25] <rashadkm> inglada: what specific tools ?
[15:25] <VictorPoughon> +1 for debiangis also
[15:25] <cresson> yes +1
[15:25] <VictorPoughon> ok, ready to move on to 5. Technical topics?
[15:26] <inglada> rashadkm: I think I don't know what xdk you mean
[15:27] <rashadkm> xdk = external development kit. this include all headers + .lib or .so needed by OTB to compile without anything else on system.
[15:27] <rashadkm> expect a compiler and cmake .
[15:27] <inglada> rashadkm: OK, in this case I agree and issue solved
[15:28] <jmichel> VictorPoughon: 1 sec, we are almost done
[15:28] <jmichel> so cnes/cs team supports standalone and debiangis
[15:28] <VictorPoughon> (jmichel: of course)
[15:28] <jmichel> maybe other from the community want to support other distribs
[15:28] <grizonnetm> BTW Angelos is maintaining OpenSUSE package for years now without problem
[15:29] <jmichel> everything else is unsupported and advertised as such on the wiki
[15:29] <cresson> Is there some doc on the wiki about packaging ?
[15:29] <gpasero> +1
[15:29] <inglada> jmichel: seems reasonable
[15:29] <VictorPoughon> cresson: http://wiki.orfeo-toolbox.org/index.php/Binary_packages_status
[15:29] <jmichel> meaning : you can install those packages but we do not know if they will work and we will not fix them
[15:29] <inglada> jmichel: +1
[15:29] <jmichel> perfect
[15:30] <cresson> I mean it could be great to give the recipe to produce the package
[15:30] <gpasero> I would also add the warning from Calibre about building from source ... nice one!
[15:30] <cresson> in order to make possible contributions from the community
[15:30] <VictorPoughon> gpasero: a bit extreme but true :)
[15:31] <jmichel> pfff, I was planning to propose gentoo packages ...
[15:31] <inglada> gpasero: we have the superbuild
[15:31] <jmichel> cresson: everything we have is in otb-devutils
[15:31] <gpasero> inglada: true !
[15:31] <inglada> and it works very well http://jordiinglada.net/wp/2015/05/27/installing-otb-has-never-been-so-easy-8/
[15:31] <cresson> ok
[15:32] <jmichel> but of course if there is someone that volunteers to make new package we will help
[15:32] <cresson> we use to have somebody involved in this
[15:33] <cresson> could be great to take back the job
[15:33] <jmichel> ok
[15:33] <jmichel> so we only need to update the wiki in order to display and enforce this packaging policy
[15:33] <inglada> not only the wiki, but also the download page
[15:33] <jmichel> yes inglada
[15:34] <jmichel> packaging manager ? or victor as release manager ?
[15:34] <VictorPoughon> I can take that action as part of release process
[15:34] <jmichel> ok sold
[15:34] <jmichel> next ?
[15:34] <VictorPoughon> === 5.1 Should Monteverdi be merged into OTB?
[15:35] <inglada> yes, next
[15:35] <jmichel> +1
[15:35] <grizonnetm> +++++1
[15:35] <VictorPoughon> ok waiting for RFco
[15:35] <inglada> ++++++++++++10
[15:35] <VictorPoughon> === 5.2 Simple OTB
[15:35] <gpasero> why not
[15:35] <jmichel> not much to say about it
[15:35] <inglada> oxymoron
[15:35] <jmichel> just that we are often asked about programming with otb in python
[15:36] <jmichel> and we are left with the app API, which is not really programming with otb in python
[15:36] <grizonnetm> cp -r SimpleITK SimpleOTB
[15:36] <jmichel> I will read the extended paper on SimpleITK, and come back with a RFCo describing what I think we could do
[15:36] <inglada> who is going to use and maintain that? which support?
[15:36] <jmichel> inglada, that is the problem
[15:37] <inglada> this is why the first OTB bindings died
[15:37] <jmichel> it is yet a new thing to maintain and package
[15:37] <gpasero> I fear it will add a lot of work for maintainance
[15:37] <VictorPoughon> besides, isn't there room for improvement in our current python bindings?
[15:37] <jmichel> I was hoping that it would be less complex than the cmake/cable-swig/gcc-xml nightmare of bindings
[15:38] <jmichel> but first looks at the code is frigthening ;)
[15:38] <gpasero> VictorPoughon: +1 for this easy way
[15:38] <jmichel> ok
[15:38] <jmichel> I will have a look
[15:38] <jmichel> and come back to you
[15:39] <VictorPoughon> ok so no PSC decision today, RFco are welcome as usual?
[15:39] <inglada> I have to go, sorry
[15:39] <jmichel> lets talk about MPI
[15:39] <VictorPoughon> === 5.3 JPEG2000 and Sentinel2 products
[15:39] <jmichel> ok inglada
[15:39] <VictorPoughon> (mpi is next)
[15:41] <jmichel> ok
[15:41] <jmichel> just to say that we have a gdal driver for S2
[15:41] <gpasero> what is the issue with JP2K & Sentinel ?
[15:41] <jmichel> but it uses the jpeg2000 driver to read the products
[15:41] <jmichel> and openjpeg driver is painly slow
[15:41] <jmichel> so in the end, it is almost not usable (especially for visu)
[15:42] <jmichel> we now have users that try to open S2 products in Monteverdi
[15:42] <jmichel> and give up
[15:42] <VictorPoughon> Call ESA?
[15:43] <jmichel> there is a version of openjpeg that is supposed to be super fast
[15:43] <jmichel> a fork
[15:43] <jmichel> I think we need to try this
[15:43] == inglada [~user@pc-117-162.ups-tlse.fr] has quit [Ping timeout: 244 seconds]
[15:43] <cresson> fast, but with approximations?
[15:44] <jmichel> I do not really know
[15:44] <VictorPoughon> Link to fork announcement: https://groups.google.com/forum/#!topic/openjpeg/F6IJ9ROz7Zg
[15:44] <grizonnetm> https://github.com/GrokImageCompression/grok
[15:44] <VictorPoughon> C++14, AGPL License
[15:44] <VictorPoughon> quote: "currently it is roughly 1/3 the perf of Kakadu, (tested on windows), and I am hoping to get it down to around 1/2"
[15:45] <gpasero> What actions on this : try to have it as a GDAL driver ?
[15:45] <jmichel> this is not really an OTB issue
[15:45] <jmichel> but if we could try to have grok as a gdal driver in superbuild (and standalone binaries), it would be great
[15:46] <jmichel> at least we need to try it
[15:46] <VictorPoughon> add it to the roadmap :)
[15:47] <VictorPoughon> === 5.4 MPI
[15:47] <grizonnetm> would be interesting to ask to snap developers their feedback about openjpeg for S2
[15:48] <jmichel> grizonnetm: good idea
[15:49] <jmichel> so, MPI
[15:49] <grizonnetm> Guillaume? Can you ask to jmalik?
[15:49] <cresson> to bring MPI in OTB we might need to re-think app wrapping
[15:49] <jmichel> I was hoping that our colleague emmanuel could join us
[15:49] <gpasero> yes, he just said that OpenJpeg is clearly slower than kakadu
[15:50] <grizonnetm> ok
[15:50] <grizonnetm> move to MPI
[15:50] <gpasero> but for him, it would be also an option to add contribution to OpenJPEG
[15:50] <gpasero> (ok, move to MPI)
[15:50] <jmichel> did he have a look at the fork ?
[15:51] <cresson> this one needs to be tested on true cluster
[15:51] <gpasero> jmichel: no, he didn't
[15:51] <cresson> :(
[15:51] <jmichel> cresson: I worked a bit with emmanuel on this topic
[15:51] <cresson> we have time
[15:51] <jmichel> +lle
[15:51] <cresson> yes
[15:52] <cresson> some time ago
[15:52] <jmichel> we also have a simpler solution
[15:52] <cresson> yes?
[15:52] <jmichel> involving extract+writer in the MPI block, and vrt file generation
[15:52] <jmichel> pros: it is very simple
[15:52] <cresson> vrt file generation is nice because we use GDAL directly
[15:52] <cresson> agree
[15:53] <jmichel> you can write WriteMPI(reader->GetOutput(),argv[2],MPIRank,MPISize); instead of calling the writer
[15:53] <jmichel> and there you go
[15:53] <cresson> yes
[15:53] <cresson> cons: IO bottleneck might arrive faster (conconrent IO tasks)
[15:54] <jmichel> We had some ideas to better hide the MPI magic by turning this to a class
[15:54] <jmichel> cresson: right
[15:54] <jmichel> this is where the parallel tif is good
[15:54] <cresson> but the output is just a point
[15:55] <cresson> bringing MPI into apps, filters, is important
[15:55] <cresson> your idea?
[15:55] <jmichel> apps could be done with both solutions
[15:55] <jmichel> filters I am not sure. Do you speak of persistent filters ?
[15:55] <cresson> filters wich need some sharing e.g. statistics
[15:55] <jmichel> ok persistent filters
[15:56] <cresson> ok
[15:56] <jmichel> I think we could work something with both solutions
[15:56] <jmichel> persistent filters is just so special filter cabled to a virtual writer
[15:56] <cresson> yes
[15:56] <jmichel> so we could call VirtualWrite(); and it would be soled
[15:56] <jmichel> solved
[15:57] <cresson> I see
[15:57] <cresson> It could be nice to work on this
[15:57] <cresson> however it's far from beeing fully integrated in OTB
[15:57] <grizonnetm> MPI team in June during the hackthon?
[15:57] <cresson> but I think it will be a great new feature
[15:57] <cresson> yes
[15:58] <cresson> could be nice
[15:58] <jmichel> I think we could work something with you and emmanuel for next release
[15:58] <cresson> CNES cluster ? :p
[15:58] <jmichel> but I would be in favour of small steps : first push a simple module that allows to use MPI
[15:58] <jmichel> then try to insert it for apps writing
[15:58] <jmichel> and so on ...
[15:59] <cresson> I agree
[15:59] <jmichel> because we will not get the big picture right in a single shot I think
[16:00] <cresson> It's a good idea to play with otb/mpi at hackton
[16:00] <jmichel> why not
[16:00] <jmichel> bring your own cluster ;)
[16:00] <cresson> ha ha
[16:01] <VictorPoughon> anything else about MPI?
[16:01] <cresson> I started to work on a branch
[16:01] <jmichel> ok
[16:01] <jmichel> maybe we could have a dedicated meeting with you cresson and Emmanuelle
[16:02] <jmichel> or you could come here to work on this together
[16:02] <jmichel> (do not know if its possible for you)
[16:03] <cresson> we can talk about it soom
[16:03] <grizonnetm> next subject?
[16:03] <VictorPoughon> === 6. Next release manager
[16:04] <jmichel> I can do it with a backup
[16:04] <grizonnetm> Jordi?
[16:04] <VictorPoughon> he's not here
[16:05] <grizonnetm> that was the reason why I suggest him :)
[16:05] <grizonnetm> ok I'll do it
[16:05] <gpasero> let's choose a backup to the backup RM in case he says no
[16:05] <jmichel> ok so me and grizonnetm as a backup ?
[16:06] <VictorPoughon> ok so Julien as RM, Jordi as backup RM and grizonnetm as backup backup RM ?
[16:06] <VictorPoughon> PSC member please vote
[16:06] <grizonnetm> I was joking about Jordi
[16:06] <jmichel> +e
[16:06] <gpasero> +1
[16:06] <cresson> +1
[16:06] <grizonnetm> we're good
[16:06] <jmichel> anything else ?
[16:06] <VictorPoughon> ok that's it for the agenda
[16:07] <grizonnetm> Victor can you log the meeting on the wiki?
[16:07] <VictorPoughon> yes
[16:07] <grizonnetm> so have a nice weekend
[16:07] <VictorPoughon> i'll also do a kick write up on the wiki
[16:07] <jmichel> bye everyone
[16:08] <VictorPoughon> thanks all
[16:08] <gpasero> thanks all, bye !
[16:08] <grizonnetm> bye
[16:08] == grizonnetm [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has quit [Quit: Page closed]
[16:08] == gpasero [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has quit [Quit: Page closed]
[16:08] <cresson> bye
[16:10] <cresson> when is the next IRC meeting?
[16:11] <cresson> else, see you in June in real
[16:11] <VictorPoughon> cresson: we thought about doing a "real" meeting for the next one
[16:11] <VictorPoughon> ;)
[16:11] <VictorPoughon> at the user days