IRC logs Monday 2017.10.12 14:00 CEST

[14:08] <gpasero> ok let's begin
[14:09] <grizonnetm> don't know
[14:09] <grizonnetm> but I don't think so
[14:09] <VictorPoughon> shall I chairman?
[14:09] <jmichel-otb> would you mind chairmanning ? ;)
[14:10] <VictorPoughon> ok here's the agenda: https://wiki.orfeo-toolbox.org/index.php/PSC_meetings#Agenda_9
[14:10] <VictorPoughon> ===== Feedback from release 6.2
[14:10] <jmichel-otb> still in RC stage ;)
[14:11] <gpasero> several bugs reported after RC
[14:11] <gpasero> some of them are fixed
[14:11] <grizonnetm> just wanted to say that it's always a good think to release an RC (deploy packages, update website) and gather feedbacks
[14:11] <jmichel-otb> when I look at the changelog, there is a lot of merged RFC, but not much of them are about new features
[14:12] == Antoine___ [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:12] <gpasero> some RFC are just minor technical improvements
[14:13] <gpasero> but since we have to do RFC anyway, I think it is normal if we have a lot of small perimeter RFCs
[14:13] <VictorPoughon> i think this release looks great
[14:13] <grizonnetm> good to see that feedbacks from otb user days brainstorming where implemented
[14:14] <jmichel-otb> yes you are right
[14:14] == cresson [~cresson@mtd201.teledetection.fr] has joined #otb
[14:14] <cresson> hi
[14:14] <gpasero> hi Rémi
[14:14] <VictorPoughon> Hi cresson ! We are talking about "Feedback from release 6.2"
[14:16] <jmichel-otb> anything to say about the process itself ? RM role ? time to merge for features ?
[14:16] <jmichel-otb> review process ?
[14:16] <gpasero> on my side, no real issue here
[14:17] <VictorPoughon> i feel like our release process is quite mature now
[14:18] <VictorPoughon> next topic ?
[14:18] <jmichel-otb> yes
[14:18] <gpasero> yes
[14:18] <grizonnetm> yes
[14:18] <VictorPoughon> ===== Choose new Release Manager
[14:19] <grizonnetm> I can take the next one if you want
[14:19] <VictorPoughon> great
[14:19] <cresson> +1
[14:19] <VictorPoughon> a volunteer for backup RM ?
[14:19] <gpasero> I can be backup RM if needed
[14:19] <VictorPoughon> +1
[14:19] <grizonnetm> but I have already been RM so if someone new want to try
[14:19] <cresson> I'll be away in december till mid january
[14:20] == inglada [~user@pc-117-162.ups-tlse.fr] has joined #otb
[14:20] <jmichel-otb> +1
[14:21] <jmichel-otb> I think that the RM could be more active in the post feature freeze stage
[14:21] <VictorPoughon> jmichel-otb: which actions specifically?
[14:21] <jmichel-otb> After feature freeze, things get a bit blurry
[14:22] <jmichel-otb> there is a todo list, but noone is responsible to make sure it moves forward
[14:22] == cpp14 [827875a2@gateway/web/freenode/ip.130.120.117.162] has joined #otb
[14:23] <VictorPoughon> well if it blocks then sure it's the RM responsibility to look into it
[14:23] == cpp14 [827875a2@gateway/web/freenode/ip.130.120.117.162] has quit [Client Quit]
[14:23] <gpasero> Then it would be the role of the RM to make things move forward
[14:23] <VictorPoughon> in the case of 6.2 we didn't have significant problems
[14:24] <VictorPoughon> next topic?
[14:24] <gpasero> The only step that is not always clear is the mantis issues that have to be closed before RC
[14:24] <jmichel-otb> yes gpasero
[14:24] <VictorPoughon> true
[14:24] <VictorPoughon> we usually discuss this offline
[14:24] <jmichel-otb> maybe it should be the RM who decides which issues have to be fixed
[14:25] <jmichel-otb> based on proposals
[14:25] <VictorPoughon> why not
[14:25] <grizonnetm> +1
[14:25] <msavinaud> this part is strongly related to the CS-CNES contract usually
[14:25] <VictorPoughon> i see the RM role more as a if-needed basis. If all is going well, no need to add a layer of bureaucracy
[14:26] <grizonnetm> it should perhaps be describe in https://wiki.orfeo-toolbox.org/index.php/Decision_making or https://wiki.orfeo-toolbox.org/index.php/How_to_Release
[14:26] <VictorPoughon> if there are deadlocks then he can have authority to resolve them
[14:26] <VictorPoughon> (he or she)
[14:27] <VictorPoughon> ok grizonnetm, as the new RM can you update the wiki pages to reflect this :) ?
[14:27] <grizonnetm> facepalm
[14:27] <VictorPoughon> :P
[14:28] <grizonnetm> ok
[14:28] <VictorPoughon> thanks
[14:28] <jmichel-otb> msavinaud: I do not know. There is a proposed list of bugs to fix. Wether cnes asks CS to fix them in the frame of the contract is something else
[14:29] <msavinaud> so the RM propose a list, CNES select into this list what it is done or not (probably all in all case). Beacasue some bugs can be time consumming
[14:30] <msavinaud> probably all in the great majorirty of case
[14:31] <jmichel-otb> In fact I would do more like : RM gathers feedback on bugs that need to be fixed. He makes a list that is public, and track the fixes to be able to get progress info on the release
[14:32] <gpasero> The RM will need to have an estimate of the resources needed to fix those bugs
[14:32] <jmichel-otb> The aim is not to impose anything, just to make more clear from the outside what is the status of the incubating release
[14:32] <jmichel-otb> gpasero: even not. But at least he can say : we can not release yet because bug #xxx is not fixed
[14:33] <jmichel-otb> RM is coordinating. Why not after feature freeze ?
[14:35] <grizonnetm> +1 to improve coordination by RM after the feature freeze
[14:35] <msavinaud> I propose (if I well understand) The RM agregate a list of bugs, this list is approved by a vote on the list and after that he can block a release until the enttire list is not fixed
[14:35] <VictorPoughon> maybe that's too bureaucratic no?
[14:36] <VictorPoughon> how about grizonnetm just try to keep things clear and focused in the next RC process
[14:36] <VictorPoughon> by keep a list of bugs, issues, a planning for the final release, etc.
[14:36] <jmichel-otb> I agree
[14:37] <jmichel-otb> we do not need something strong (votes, blocking a release), there are no cases where we should have voted or blocked a release
[14:38] <grizonnetm> RM can manage this list of bug in Mantis and mark them as severity = 'block' for those which should be fix before the release
[14:38] <jmichel-otb> but a little more information to RM and community would not hurt
[14:38] <gpasero> I agree on the "coordination" role
[14:38] <msavinaud> ok the RM coordinate now the list of bugs to be fixed and communicate on the progress
[14:38] <VictorPoughon> great
[14:38] <jmichel-otb> good
[14:38] <VictorPoughon> we have many more topics, next?
[14:38] <grizonnetm> yes
[14:39] <msavinaud> I am ok on the coordination role
[14:39] <VictorPoughon> ===== Status of remote modules: binary packages, official remote vs remote, status of merge attempts into OTB
[14:39] <grizonnetm> @VictorPoughon: can you note to copy the log of the meeting to the wiki at the end of the irc meeting?
[14:40] <VictorPoughon> grizonnetm: yes
[14:40] <jmichel-otb> most remote modules are official no ?
[14:41] <jmichel-otb> and now they are packaged in same package as OTB
[14:41] <gpasero> yes, most of them
[14:41] <gpasero> but Jordi's modules are still missing
[14:41] <jmichel-otb> TemporalGapFilling is there
[14:41] <grizonnetm> to package Jordi's module we need to add gsl to the superbuild
[14:43] <grizonnetm> something we can perhaps have a look for the next release
[14:43] <jmichel-otb> yes
[14:43] <inglada> first issue will be gsl availability on windows
[14:44] <cresson> and working with splines
[14:44] <jmichel-otb> About migrating Remote Modules to core, is it actually something we need to do ?
[14:45] <VictorPoughon> jmichel-otb: you mean official remote modules?
[14:45] <jmichel-otb> yes
[14:46] <jmichel-otb> I mean, if they are up and working, with someone behind, why should we spend efforts on merging them ?
[14:47] <jmichel-otb> The only case that would require a merge is abandonned remote modules
[14:48] <gpasero> I see one potential reason to migrate a remote module : if it make sense to integrate its feature in an existing OTB framework (machine learning ,...) or if there is a partial duplicated feature...
[14:48] == rkm [~rkm@4.235.17.93.rev.sfr.net] has joined #otb
[14:49] <cresson> I agree with Julien: as a remote module maintainer, it's easyier to add new features and corrects issues wihout RFC/votes workflow
[14:49] <jmichel-otb> cresson: agreed
[14:49] <VictorPoughon> fine with me
[14:49] <jmichel-otb> gpasero: yes, I think our effort should be directed toward duplicated features
[14:49] <cresson> gpasero is also right
[14:49] <jmichel-otb> LSOBIA variants for instance
[14:50] <jmichel-otb> but this does not mean we need to merge in core
[14:50] <VictorPoughon> ok so, no action needed on this topic then?
[14:51] <jmichel-otb> RM could make sure that there are no forgotten remote modules
[14:51] <Antoine___> Would Integrating a remote module in the core a reward and a recognition for the writter?
[14:51] <VictorPoughon> If they prefer sure we can do it, but from remi's comment it seems like they would prefer to not be integrated
[14:51] <jmichel-otb> Antoine___: agreed, bu technically they are already integrated in dashboard and packaging and cmake conf
[14:52] <jmichel-otb> + advertised on website
[14:52] <cresson> My comment was about non-mature remote module
[14:52] <jmichel-otb> anyway I am not saying we should never do it, rather that there is no need to spend time on it if there are no needs
[14:53] <VictorPoughon> I think maybe this issue is different for each remote module, some will prefer to stay independent, others will like to be integrated, or need to for technical reasons (refactoring, deduplication, reuse, etc.)
[14:53] <cresson> yes VictorPoughon
[14:53] <jmichel-otb> ok
[14:53] <VictorPoughon> next topic then :) ?
[14:54] <jmichel-otb> yes
[14:54] <VictorPoughon> (note: I am adding "Ossimgate: status of ossim dependency and debian packaging issues" to the agenda)
[14:54] <kalxas> hi all (just saying hi, not part of the PSC :)
[14:54] <Antoine___> What i mean is that spending time on a finished and mature module does not seem to be a waste of time (IMO)
[14:54] <cresson> hi kalxas
[14:54] <VictorPoughon> hi kalxas , comments are welcome anyway :)
[14:54] <Antoine___> But yes! Next topic Victor! :)
[14:54] <cresson> of course
[14:55] <VictorPoughon> ===== Deadline for RFC vote (discussion on otb-developers in August) : Suggestion "Make sure each RFC is at least 3-days old (since official announce on otb-developers) before merging it" If done PSC status should be updated and an item in ReleaseManager's checklist added.
[14:56] <jmichel-otb> not really in favour
[14:56] <jmichel-otb> accepting and merging already takes too much time
[14:56] <VictorPoughon> I am against this personnaly, given that reverting a feature branch merge has never been needed so far, and if we do need to do it git supports it well. We should keep the option to merge fast if it is ready fast IMO. If a -1 comes later we will deal with it when it actually becomes a problem
[14:56] <jmichel-otb> and rfc get easily forgotten
[14:57] <cresson> agreed
[14:57] <VictorPoughon> ok next topic?
[14:57] <grizonnetm> ok
[14:58] == sdinot [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[14:58] <gpasero> in real OTB life, the merge always happens at least 3 days after announce
[14:58] <VictorPoughon> gpasero: true
[14:58] <VictorPoughon> welcome sdinot :)
[14:58] <sdinot> Hi !
[14:58] <gpasero> I understand if you don't want to make it a law
[14:59] <VictorPoughon> if it becomes a problem sure, but right now it's not a problem
[14:59] <gpasero> maybe it could rather be a "soft guideline"
[15:00] <jmichel-otb> gpasero: can you reexplain the rationale for the 3 days ?
[15:01] <gpasero> just to make sure a PSC member has the time to check an RFC, and (if needed) put a veto before approval
[15:02] <VictorPoughon> idea: we explain in the wiki that a -1 can come up to 3 days AFTER a merge, in which case the merge must be reverted immediatly
[15:02] <gpasero> as we don't have had any -1 so far, I am not convinced we need it
[15:02] <VictorPoughon> ok ok
[15:02] <cresson> the law should be good review before vote
[15:02] <Antoine___> I agree with guillaume, plus I do not see a case where there is an emergency and we need to merge directly after vote...
[15:02] <jmichel-otb> let's not add new rules if not needed
[15:03] <jmichel-otb> cresson: agreed
[15:03] <VictorPoughon> jmichel-otb: let's add that into a rule ;)
[15:03] <cresson> ;)
[15:04] <VictorPoughon> next topic?
[15:04] <gpasero> yes
[15:04] <jmichel-otb> Antoine___: actually most merges happens after 3 days already. Because dashboard need to be green and RM need to give green light (and he is always busy somewhere else)
[15:04] <jmichel-otb> but lets add a soft guideline to prevent quick merges
[15:05] <VictorPoughon> jmichel-otb: unenforceable rule to prevent a non existent problem
[15:05] <VictorPoughon> great
[15:06] <grizonnetm> +1 for soft guideline as suggested by gpasero (@gpasero -> you're in charge of adding it?)
[15:06] <gpasero> okay
[15:06] <VictorPoughon> ok
[15:06] <VictorPoughon> ok next topic
[15:06] <VictorPoughon> ===== Infrastructure migration: gitlab self-hosted instance or github.com?
[15:07] <jmichel-otb> and the troll awakens ;)
[15:07] <grizonnetm> winter is coming...
[15:07] <inglada> I propose to move this conversation to slack
[15:08] <jmichel-otb> you mean https://github.com/maknz/slack
[15:08] <sdinot> or on the mattermost server provided by Gitlab :)
[15:08] <msavinaud> I think we should decide because it blocks some actions for Sebastien
[15:09] <VictorPoughon> ok the actual topic is: is there any strong oposition to moving OTB developement (feature and realease branches) to Github PR system
[15:09] <jmichel-otb> let aside the ethical concerns, what does it imply for our organization ? Can we do a quick brainstorming on what needs to be done and how ?
[15:10] <jmichel-otb> FYI, gdal operates this move as we speak
[15:10] <VictorPoughon> git remote set-url origin https://github.com/orfeotoolbox/OTB.git # done.
[15:10] <jmichel-otb> VictorPoughon, actually I do not think so
[15:10] <jmichel-otb> are sure you can push patches to the github mirror ?
[15:11] <VictorPoughon> no of course, we need to stop the mirroring script and update access permissions
[15:11] <VictorPoughon> Did you see there is a draft migration plan in my RFC ;) ? https://wiki.orfeo-toolbox.org/index.php/Request_for_Comments-40:_Move_to_GitHub#Migration_plan
[15:12] <jmichel-otb> do we migrate the wiki ?
[15:12] <VictorPoughon> that's up for debate also
[15:13] <VictorPoughon> I am in favor, personnaly
[15:13] <jmichel-otb> what about travis-ci ?
[15:13] <jmichel-otb> rkm: you did work on that right ?
[15:14] <VictorPoughon> travis-ci is unrelated to this topic IMO, as it can work with the mirror
[15:14] <VictorPoughon> but would be great to have still
[15:14] <sdinot> https://travis-ci.org/orfeotoolbox/OTB
[15:14] <jmichel-otb>  Duration: 10 sec  Finished: 10 months ago
[15:15] <cresson> fast
[15:15] <jmichel-otb> Either it builds OTB really fast or there is still work to do
[15:15] <rkm> jmichel-otb: some time ago
[15:15] <rkm> https://github.com/orfeotoolbox/OTB/tree/develop/Utilities/Maintenance
[15:15] <jmichel-otb> anyway not really related
[15:16] <rkm> this is ci script we use : https://github.com/orfeotoolbox/OTB/blob/develop/Utilities/Maintenance/TravisBuild.sh
[15:17] <jmichel-otb> nobody seems really against. Are we afraid to make this step ?
[15:17] <jmichel-otb> inglada: no opinion ?
[15:17] <gpasero> On my side, I don't see any strong blocker to move to a github/gitlab solution
[15:17] <cresson> me neither
[15:18] <VictorPoughon> same, some technical issue but nothing major. It would be nice to follow ITK and the rest of the world on this.
[15:18] <rkm> ...and it a'int complete without windows: https://ci.appveyor.com/project/gpo-geo/otb/build/0.2.3
[15:18] <VictorPoughon> rkm: that's awesome
[15:20] <msavinaud> for me github and gitlab are two equivalent solutions to improve code reveiw and code contribution
[15:20] <gpasero> small question : if someone wants to do a PR, he/she still has to follow the RFC process ?
[15:21] <VictorPoughon> gpasero: Yes of course. In my RFC I suggest that the RFC process is kept identical, but the +1/-1 votes and the "go for merge", technical discussion, etc. can happen in the dicussion of the PR. This will clean up the otb-developpers list a bit
[15:23] <inglada> Is this the first step to completely close down OTB's infrastructure? Moving to github, even only the repository is a gateway drug.
[15:23] <grizonnetm>  note that we've merged  Daniel's PR in develop in September without following the RFC process and feature branches (besides it was related only to the documentation)
[15:25] <gpasero> inglada: can you detail your concerns ?
[15:25] <VictorPoughon> inglada: define "close down". IMO the current process is more closed down to external users than github.
[15:25] <VictorPoughon> current infrastructure I mean
[15:26] <inglada> Infrastructure = git repo, wiki, bugtracker, dashboard, etc.
[15:27] * VictorPoughon grabs popcorn
[15:27] <inglada> OK VictorPoughon I am concerned by you weight gain. I quit.
[15:28] <VictorPoughon> we can always move back if it doesn't work out. I will be happy to admit I am wrong
[15:29] <VictorPoughon> (we have more topics to discuss after this)
[15:29] <jmichel-otb> If we move to github, will anyone stop contributing ?
[15:31] <jmichel-otb> inglada: I think dash + website + blog will still exist in any case
[15:31] <VictorPoughon> yes
[15:31] <msavinaud> for me it will not necessarily increase the number of contribution
[15:32] <sdinot> website + blog could be replaced by github pages and a static generator like Jekyll
[15:32] <sdinot> msavinaud: +1
[15:32] <VictorPoughon> msavinaud: not necessarily no. this is only one of the reasons described in the rfc
[15:32] <msavinaud> people can currently do PR. I hope we will not refuse this contribution because it didn't follow the current guidelines
[15:33] <VictorPoughon> we already accept github PR for minor contributions (outside of RFC process). The proposal is to move all developmement to github hosted platform
[15:33] <VictorPoughon> I mean main development sorry, git is decentralized so you are free to not use it actually
[15:33] <sdinot> I am afraid that the main gates are the language (C++) and the field (remote sensing / image processing), not the development environment.
[15:34] <rkm> sdinot: +1
[15:34] <jmichel-otb> To put things in perspective, we start from: complaints about code review in emails (which I can not disagree with), and plans to move to gitlab
[15:34] <VictorPoughon> all the more reason to make it more user friendly with a proper code review tool
[15:34] <gpasero> I am curious to have some feedback from cmake (as they use GitLab)
[15:35] <jmichel-otb> so for me the question is : do we invest money in setting up a gitlab instance
[15:35] <jmichel-otb> approx. same migration costs + new infrastructure costs
[15:36] <jmichel-otb> or do we move to github to save the infrastructure costs
[15:36] <VictorPoughon> and use a state of the art code review tool
[15:36] <VictorPoughon> and be closer to the osgeo community
[15:36] <msavinaud> To solve issue with code review gitlab can be as github a solution. For me the two solutions are equivalent (the cost to hosting a gitlab with wiki and issue tracker is not a strong argument for me)
[15:36] <jmichel-otb> VictorPoughon: gitlab has also state of the art review
[15:37] <VictorPoughon> jmichel-otb:
[15:37] <VictorPoughon> jmichel-otb: yes
[15:37] <grizonnetm> I've got to go (other meeting)
[15:37] <jmichel-otb> but in the gitlab case : we manage accounts, we mange security ...
[15:39] <grizonnetm> there are also different versions of gitlab (community -> open, enterprise -> close) with different functionalities.
[15:39] <msavinaud> we have exposed all the argument I think can we move to a vote ?
[15:40] <jmichel-otb> ok, but status quo is not an option
[15:40] <jmichel-otb> so vote is between gitlab and github
[15:40] <msavinaud> yes I think that everyone must vote for one the solution
[15:41] <msavinaud> Gitlab for me
[15:41] <gpasero> okay : +1 for gitlab
[15:41] <cresson> +1 for gitlab
[15:42] <VictorPoughon> +1 for github
[15:43] <sdinot> +0.5 for gitlab... 0.5 because I am not involved in the development. ;)
[15:45] <jmichel-otb> so if i vote github it is a psc tie
[15:47] <jmichel-otb> thing is I do not know, so I will not vote
[15:47] <jmichel-otb> If there were more people in PSC, we could have a clearer vote ...
[15:49] <VictorPoughon> Did anyone actually read my RFC? I feel like I make valid points which were not objected to in the discussion. The entire OSGeo community is slowly moving to github while we waste time on philosophical considerations, not technical ones.
[15:50] <VictorPoughon> but this meeting needs to move on
[15:50] <VictorPoughon> so fine with gitlab
[15:50] <VictorPoughon> next topic
[15:50] <VictorPoughon> ===== Discussion about release a 6.0.1 with some back-ported fixes
[15:50] <msavinaud> ok
[15:50] <jmichel-otb> +1
[15:50] <msavinaud> I propose it
[15:51] <msavinaud> because it is the last release with C++98 and C++11 compatibility
[15:52] <jmichel-otb> I hope backported patches have no c++14 inside ;)
[15:52] <gpasero> +1
[15:52] <msavinaud> no for example it is to solve issue with expat and qt on macos
[15:54] <msavinaud> we propose to manage this release at cs and to identify with the PSC the backported fixes
[15:56] <msavinaud> have you other suggestions about the content of this 6.0.1 release ?
[15:56] <VictorPoughon> ok for me. Can you start with a list of patches to backport and send it to otb-dev?
[15:56] <jmichel-otb> good
[15:57] <msavinaud> ok victor I will do that : for the moment we have only identified the patch about expat and the patch about macosX
[15:57] <VictorPoughon> (3 topics remaining btw)
[15:57] <VictorPoughon> msavinaud: great
[15:57] == Yannick [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has quit [Ping timeout: 260 seconds]
[15:57] <VictorPoughon> next topic?
[15:57] <jmichel-otb> go
[15:57] <VictorPoughon> ===== Discussion about provide a release-6.2-C++(11/98)-compatibility branch with associated binary packages
[15:58] <VictorPoughon> what is the rationale for this one?
[15:58] <jmichel-otb> -1
[15:59] == Antoine___ [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has quit [Ping timeout: 260 seconds]
[15:59] <msavinaud> To explain the subject, we have encounter some issue with installation in a CentOS7 docker
[15:59] <msavinaud> due to gcc version
[16:00] <VictorPoughon> yes, I am also on CentOS 7. I now use the devtoolset-6 package to build otb with gcc 6.2.1
[16:00] == Antoine___ [5d11eb04@gateway/web/freenode/ip.93.17.235.4] has joined #otb
[16:00] <jmichel-otb> we dropped compatibility with C++98, remember ?
[16:01] <msavinaud> yes
[16:01] <jmichel-otb> We are not going to maintain two versions of the code eternally
[16:01] <jmichel-otb> I agree that we can backport patches to 6.0.1
[16:01] <gpasero> check mantis-1451
[16:02] <gpasero> we may have found a way to build using c++14 and still provide binaries compatible with CentOS6 & 7 and even Ubuntu precise
[16:02] <rkm> hmm.. half-time spend on getting as many external contributions(github, gitlab...) and other half-time spend on blocking (c++14, 17, 20..)
[16:03] <jmichel-otb> gpasero: good. So it makes this proposal useless no ?
[16:03] <VictorPoughon> we are not going to maintain otb in two different languages anyway
[16:04] <gpasero> well
[16:04] <msavinaud> yes
[16:04] <gpasero> as long as the user doesn't need to re-build, or develop with SDK , it's okay
[16:04] <msavinaud> I didn't update with Guillaume before the meeting
[16:05] <jmichel-otb> gpasero: VictorPoughon is on centos7 and can build otb at will
[16:05] <msavinaud> If you find a solution for binaries packages it is ok for me
[16:06] <VictorPoughon> next topic?
[16:06] <gpasero> yes
[16:06] <VictorPoughon> ===== Discussion about C++14 strategy and its impact on users.
[16:07] <rkm> VictorPoughon: you are saying it is different language? i thought it was a standard chnage?
[16:07] <msavinaud> Have you some feedback from users or new developers about this previous decision ?
[16:07] <VictorPoughon> (rkm: Fair enough. I was exagerating to make a point)
[16:08] <gpasero> About users, I haven't had any feedback on the C++14,
[16:08] <rkm> msavinaud: user's (people who don't want to code) dont care what lang is used.
[16:08] <jmichel-otb> ok so developers, express yourself
[16:08] <VictorPoughon> I think this comes from the discussion about the use of the auto keywork on the list. But what does the PSC need to discuss here actualy?
[16:09] <cresson> developers just need to update gcc to >= 6
[16:09] <cresson> and still use their own coding fashion
[16:09] <cresson> no big deal
[16:09] <gpasero> About developers, some of us still code as they did in C++98, but now start to add drops of C++14
[16:10] <cresson> That's true
[16:10] <VictorPoughon> that's fine
[16:10] <VictorPoughon> C++14 is allowed, not mandatory
[16:10] <rkm> cresson: you might have missed some review notes from Luc.
[16:10] <cresson> rkm, I know
[16:11] <cresson> Every post of Luc is a C++ course for me
[16:11] <VictorPoughon> next topic?
[16:11] <gpasero> yes
[16:11] <msavinaud> ok thanks for the explanation
[16:12] <VictorPoughon> ===== Ossimgate: status of ossim dependency and debian packaging issues
[16:13] <rkm> VictorPoughon: are we opening that gate?
[16:13] <rkm> okay
[16:13] <rkm> ossim replied on debian-gis saying threre are always fixing stuff and other things (check list)
[16:14] <rkm> and on github, one dev commented that there was hurricane in florida, so he cannot fix jsoncpp and other issues fast.
[16:14] <jmichel-otb> I also wrote to ossim and oscar to suggest they adopt a release candidate
[16:14] <jmichel-otb> lets be pragmatic and calm down on this issue
[16:14] <jmichel-otb> are the problem fixed ?
[16:15] <rkm> they gotta do what they do. keep ossim not forked!
[16:15] <rkm> we gotta do fork and maintain it
[16:16] <jmichel-otb> I think the fork word is a bit strong - since we never planned to offer to the community a replacement for ossim - only for ourselves
[16:16] <jmichel-otb> but are the issues fixed right now or are they not ?
[16:16] <rkm> yes. exactly my point, we cannot manage two projects,
[16:17] <rkm> maybe one single module in OTB
[16:17] <rkm> i don't know for sure about all issues.. need to check. but it's always same ball game with them
[16:18] <rkm> instead of putting money on this part by part, put for once and get out of this mess.
[16:18] <msavinaud> maybe continue to decrease progressively our dependance to ossim
[16:18] <rkm> my 2 cents
[16:18] <gpasero> is it possible to stick to the old 1.8.20-3 version ?
[16:19] <gpasero> maybe ask them to maintain a stable branch for this
[16:19] <rkm> gpasero: for some time yes. but what if debian and ubuntu move to newer version? DaytonaBeach.
[16:19] <rkm> gpasero: that won't work. it like having changes for us in their repo?
[16:19] <gpasero> I thought in DebianGIS we were the only project using Ossim ?
[16:20] <rkm> yes we are only one. but if there is a new one, debian upgrades to it, like otb.
[16:20] <gpasero> it would not be the first project to exist in 2 major versions in paralle;l
[16:20] <rkm> maybe you can ask an exception to debian-gis team to never upgrade ossim
[16:21] <rkm> you mean?
[16:21] <gpasero> for instance, there are packages for Qt4 and Qt5
[16:21] <gpasero> there could be packages for ossim and Ossim2
[16:21] <rkm> well, you cannot compare ossim with qt and gcc,
[16:22] <rkm> anyway, ask them and see if he is willing.
[16:23] <gpasero> I know it is not the best position for the packager,
[16:24] <gpasero> or if you prefer : ossim-1.8 and ossim
[16:26] <jmichel-otb> rkm: you are fixing a lot of things related to ossim and I can see that you developed a strong case against them
[16:26] <gpasero> anyway, we must also check if the Ossim project really wants to provide support
[16:27] <jmichel-otb> but maybe they could improve no ? If they do RC and we can provide feeddback, it would help ?
[16:28] <jmichel-otb> I am not saying we should not remove the ossim dependency, but I would prefer we do not do it out of anger
[16:29] <jmichel-otb> because that is not really the OS spirit, right ?
[16:29] <rkm> jmichel-otb: not out of anger. if you count effort spend on it vs outcome we have. that pure maths
[16:29] <rkm> nothing to do here with developer team
[16:30] <rkm> btw, effort spend == $$
[16:32] <gpasero> any more comments on this ?
[16:32] <VictorPoughon> (not from me)
[16:32] <jmichel-otb> my opinion is that if things are fixed lets keep things like this until next ossim release
[16:33] <cresson> not me either
[16:33] <jmichel-otb> we will see if we still encounter issue
[16:33] <jmichel-otb> because removing ossim dependency is also $$$$
[16:33] <VictorPoughon> ok let's wrap it up
[16:33] <gpasero> ok
[16:34] <VictorPoughon> thanks everyone for participating