IRC logs Monday 2016.11.14 3:00 PM CEST
From OTBWiki
#otb: (no topic set) [14:55] == grizonnetm [c2c7ac21@gateway/web/freenode/ip.194.199.172.33] has joined #otb [15:00] <jmichel> hi [15:01] <jmichel> rkm: was busy doing something else at 2.30 [15:01] <grizonnetm> h [15:02] <rkm> jmichel: no problem. i went for lunch a bit late :( [15:03] <rkm> i will call back after this meeting if you are free? [15:03] <jmichel> ok [15:03] <grizonnetm> I be responsible of listing decisions and copy minutes to the wiki for this meeting if it's ok [15:03] <jmichel> grizonnetm: good [15:03] <jmichel> are we expecting someone else ? [15:04] <jmichel> Victor should be there [15:04] == GrayShade [~quassel@unaffiliated/grayshade] [15:04] == realname : GrayShade [15:04] == channels : #otb [15:04] == server : sinisalo.freenode.net [SE] [15:04] == away : All Quassel clients vanished from the face of the earth... [15:04] == : is using a secure connection [15:04] == account : GrayShade [15:04] == End of WHOIS [15:05] == jmichel [c2c7ac21@gateway/web/freenode/ip.194.199.172.33] [15:05] == realname : 194.199.172.33 - http://webchat.freenode.net [15:05] == channels : #otb [15:05] == server : herbert.freenode.net [Webchat] [15:05] == idle : 0 days 0 hours 1 minutes 7 seconds [connected: Mon Nov 14 14:14:33 2016] [15:05] == End of WHOIS [15:07] <jmichel> incoming [15:07] == VictorPoughon [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has joined #otb [15:08] <grizonnetm> can we start? [15:08] <gpasero> yes [15:08] <VictorPoughon> hello [15:08] <grizonnetm> the current agenda: [15:09] <grizonnetm> Agenda Feedback from release 5.8 Choose new Release Manager Changing licence to Apache v2.0 (status) 5.10 or 6.0 ? What to do next ? [15:09] <grizonnetm> something else to add? [15:09] <jmichel> how to make PSC meetings more attractive to external people ? [15:09] <VictorPoughon> s/PSC/OTB [15:09] <VictorPoughon> ok grizonnetm let's go [15:10] <grizonnetm> Feedback from release 5.8 [15:10] <grizonnetm> a great release manager and a great release [15:10] <grizonnetm> anything else? [15:11] <jmichel> how long between ff and fr ? [15:11] <grizonnetm> 4 weeks [15:11] <VictorPoughon> but many bugs fixed, right? [15:11] <rkm> 31 days - 1 jour de ferier [15:12] <gpasero> many bugs fixed, and also a lot of work on packaging (shark,...) [15:12] <jmichel> so next one will be shorter ? ;) [15:12] <VictorPoughon> jmichel: only if you add less bugs :) [15:12] <gpasero> we hope so, unless new dependencies come around [15:13] <grizonnetm> main issue in the feature freeze period is that it's almost mandotory to merge bach release branch to develop as develop branch as a better dashboard coverage [15:14] <VictorPoughon> grizonnetm: why is it an issue? [15:14] <gpasero> coverage for release branch seems sufficient to me [15:14] <jmichel> I understand lot of work has been done during ff, the point is to solve remaining inneficiencies in the process [15:15] <jmichel> like the one grizonnetm pointed out [15:15] <grizonnetm> the process works pretty well IMHO (the how to release has been updated and it's pretty easy to follow) [15:16] <rkm> i do have some remarks [15:16] <jmichel> ok, but I still feel that we have a "A: wait until tomorrow, try to fix, goto A" loop [15:17] <VictorPoughon> jmichel: the only significant task timewise is fixing bugs that are "blocking for release", otherwise a release would take 3 days max [15:17] <rkm> we need more vm's to test all configuration equally. [15:17] <jmichel> rkm: +1 [15:18] <rkm> currently on windows: (raoul and megatron) only develop, release , remotemodules + 1 feature branch is possible [15:18] <gpasero> jmichel : for this issue, I would propose to re-introduce "continuous" builds [15:20] <jmichel> gpasero: +1 [15:20] <grizonnetm> continuous would have been really useful especially during the feature freeze for 5.8 [15:21] <jmichel> the are not inneficiencies appart from what is inneficient ;) [15:21] <jmichel> (says the guy that has been on vacation the whole ff) [15:22] <rkm> jmichel: i agree that and i was not off for ff :) [15:22] <VictorPoughon> But how does introducing continuous builds solve the issue of not having enough ressources for all the builds we want to do? [15:23] <gpasero> These resources would be used during the day, nightly build should run only at night time [15:24] <jmichel> moreover, I think we do not need as much configurations as for nightly [15:24] <grizonnetm> do we have recommandations /scripts /tutorials/otb_common macros to set up continuous build on cdash? [15:25] <gpasero> The otb_common.cmake is supposed to be able to run continuous builds [15:25] <rkm> imho, unlike earlier, continuous must be on commit basis [15:25] <rkm> that is for what commit comes to one branch and if there are multiple commits, it will kill the old one to start new one [15:25] <grizonnetm> ok good [15:26] <VictorPoughon> so like travis-ci [15:26] <rkm> yes. but the similarity is just coincidental :) [15:27] <grizonnetm> we can try to restore travis-ci using the xdk [15:27] == nhv [~chatzilla@2601:18e:c501:b7f0:f966:2cfa:2b6e:afb4] has joined #otb [15:27] <rkm> it was using xdk always. but there is crash due to memory usage. [15:27] <rkm> travis does not provide enough for "free" projects [15:28] <rkm> mostly this happen in building OTBApplicationEngine in the past [15:29] == nhv [~chatzilla@2601:18e:c501:b7f0:f966:2cfa:2b6e:afb4] has left #otb [] [15:29] <rkm> what i also struck me last two release was if there is a testing for packages afer it was generated we could have caught a lot of issues sooner. [15:29] <VictorPoughon> Will introducing continuous builds shorten the latency between "bug fix pushed" and "let's check the new package"? i.e. is a continuous build identical with a nightly build (same output). If yes why do we have nightly at all? [15:29] <rkm> i am not saying we must put more time into packaging that we already had [15:30] <VictorPoughon> What I'm saying is that if we have good continuous then we don't need nightly. (and the contraposition) [15:32] <VictorPoughon> (ok moving on) PSC please vote to conclude this item: "Good release everyone. Let's keep the same process for now. Look into introducing continuous builds and see if that helps." [15:32] <gpasero> A nightly build is more adapted to compare test results on different platforms for the same commit [15:33] <VictorPoughon> +1 [15:33] <grizonnetm> +1 [15:33] <gpasero> +1 [15:34] <grizonnetm> next topic? [15:34] <jmichel> +1 [15:34] <VictorPoughon> yes [15:34] <grizonnetm> Choose new Release Manager [15:34] <VictorPoughon> any volunteer? [15:34] <rkm> nobody? [15:35] <gpasero> I can do it [15:35] <grizonnetm> ok [15:36] <jmichel> ok [15:36] <VictorPoughon> ok +1 for gpasero [15:36] <grizonnetm> next topic [15:36] <grizonnetm> Changing licence to Apache v2.0 (status report) [15:36] <grizonnetm> request for comments completed [15:37] <grizonnetm> https://wiki.orfeo-toolbox.org/index.php/Requests_for_Comments-12:_Changing_licence_to_Apache_v2.0 [15:38] <grizonnetm> Sebastien has developed scripts to automate the migration: https://git.orfeo-toolbox.org/otb-devutils.git/tree/HEAD:/LicenseMigration [15:38] <VictorPoughon> what is your time estimate to completion? [15:38] <jmichel> can we not move the MW IO to a remote module instead of removing it ? [15:38] <grizonnetm> we're just waiting for a last approval of CNES (legal service) [15:39] <grizonnetm> and also contributor agreements from Remi Cresson (IRSTEA) [15:40] <grizonnetm> IMHO we can complete the migration before the end of the year [15:40] <VictorPoughon> grizonnetm: cool [15:41] <grizonnetm> request for comments have to be move to a RFC and vote by the PSC [15:41] <rkm> ah. new year.. new license [15:41] <rkm> i like that [15:41] <VictorPoughon> rkm: new compiler :) [15:41] <grizonnetm> one point to decide [15:42] <grizonnetm> are we doing otb 5.10 or 6.0 with only the license change [15:43] <grizonnetm> or do we want to include more feature in the release (changing license will be a feature branch) [15:43] <rkm> VictorPoughon: i already have [15:43] <gpasero> If possible, why not adding other features in the next release [15:44] <VictorPoughon> I say follow normal release schedule [15:44] <VictorPoughon> and call the next one 6.0 [15:45] <jmichel> I do not see user shift to a release that only has a licence change ;) [15:45] <jmichel> if she is not already violiting the CEcill ;) [15:45] <grizonnetm> true [15:45] <VictorPoughon> anything else? [15:45] <jmichel> ok, so 6.0, with new features, by the end of the years ? [15:46] <jmichel> Good luck guys, I just remembered I'll be off until january ;) [15:46] <VictorPoughon> jmichel: whenever the next FF is. There is no need to change the schedule [15:46] <grizonnetm> Spring 2017 [15:46] <grizonnetm> ? [15:46] <jmichel> Major releases are supposed to have major changes [15:47] <grizonnetm> agree with Julien [15:47] <jmichel> hard to do this within 3 months ever [15:47] <gpasero> jmichel: +1 [15:47] <VictorPoughon> license change is major [15:47] <VictorPoughon> ? [15:47] <gpasero> this is an opportunity if we have API changes to make [15:47] <rkm> one point that needs psc attention after other topic is on compiler support. https://wiki.orfeo-toolbox.org/index.php/Compilers [15:48] <rkm> the graph below is a copy-paste from itk. but needs some attention from governance team [15:49] <jmichel> VictorPoughon: is it ? [15:50] <jmichel> because another option is to go on with 5.X and have licence change in 5.10 [15:50] <jmichel> gdal does not move major versions so often for instance [15:51] <gpasero> I am fine with an OTB 5.10 with new licence [15:51] <jmichel> VictorPoughon is talking me into considering a licence change as a major change ;) [15:52] <jmichel> so why not : do 5.10 and keep licence change and 6.0 for spring release ? [15:53] <grizonnetm> keeping license change outside otb is dangerous [15:53] <grizonnetm> potentially new contributors can come [15:53] <VictorPoughon> this is bikeshedding to me [15:53] <VictorPoughon> I vote neutral: +1 for either 5.10 or 6.0 [15:54] <rkm> neutral is +0 [15:54] <VictorPoughon> I vote golden ratio [15:55] <gpasero> I would say +1 for licence change in 6.0 considering that it will make the 6.0 release more visible and attractive [15:56] <jmichel> ok here is what I propose : [15:57] <jmichel> let see if licence change is ready for next release [15:57] <jmichel> if so we call it 6.0 [15:57] <jmichel> otherwhise it will be 5.10 [15:57] <jmichel> and we stick to the 3 months plan (sort of) [15:57] <grizonnetm> ok [15:58] <VictorPoughon> Let's find an agreable solution and call it (6.0 + 5.10) / 2 == 5.55 [15:58] <jmichel> I think that 6.0 should get more wheight [15:58] <VictorPoughon> linear regression with gaussian prior ?? [15:58] <grizonnetm> * how to make PSC meetings more attractive to external people ? [15:58] <grizonnetm> next topic [15:59] <jmichel> ok jokes aside, do we agree on my proposal ? [15:59] <rkm> +1 [15:59] <VictorPoughon> +1 [15:59] <gpasero> +1 [16:00] <grizonnetm> next topic [16:00] <grizonnetm> how to make PSC meetings more attractive to external people ? [16:01] <grizonnetm> attendance fee? [16:01] <jmichel> let's face it : VictorPoughon grizonnetm and I could meet in the corridor anytime, and rkm and gpasero are not far away either [16:01] <jmichel> and we are the only one talking ... [16:01] <rkm> having disussion on #osgeo ? [16:02] <jmichel> rkm: why not [16:02] <grizonnetm> ok next online meeting on #osgeo [16:03] <jmichel> will they accept us ? :) [16:03] <VictorPoughon> we need to ask them first, no? [16:03] <jmichel> if we want more people around we can go to a cafe ;) [16:03] <rkm> sure. they will [16:03] <jmichel> I would rather see more people interested in what we discuss [16:03] <gpasero> having more people around also means longer discussions [16:03] <rkm> we can announce it on osgeo list. currently there are ~34 people and most of them are interested in otb [16:03] <gpasero> the choice of new features could bring some interests for the users/developer [16:04] <jmichel> and that maybe means changing what is actually discussed to something interesting for others [16:04] <gpasero> if we organize a king of live survey, people may want to give their opinion in real tim [16:04] <rkm> and will also result in external entities in psc [16:04] <gpasero> *kind [16:06] <jmichel> grizonnetm: any opinion ? [16:08] <grizonnetm> agree to discuss on osgeo but we need to discuss subjects on interest for them [16:08] <grizonnetm> completion of osgeo incubation for OTB [16:08] <grizonnetm> new features in OTB [16:08] <grizonnetm> OTB in QGIS [16:08] <grizonnetm> ... [16:08] <VictorPoughon> ok +1 then [16:08] <jmichel> OTB at foss4g(eu) [16:08] <grizonnetm> ossim in otb [16:08] <gpasero> +1 with grizonnetm [16:09] <jmichel> otb in geo4all ... [16:09] <rkm> wait for otb in qgis. we have encore discussion with @voyala from qgis team. [16:09] <jmichel> osgeo4w ... [16:09] <rkm> jmichel: don't get me started on that [16:09] <rkm> that is a joke :) [16:10] <gpasero> why not simply keeping #otb channel for 100% OTB decisions, and communicate on other channels to get more people [16:11] <gpasero> like, posting in #osgeo "feel free to join #otb for PSC meeting" [16:11] <gpasero> or a tweet [16:12] <jmichel> or psc meeting on twitter [16:13] <grizonnetm> if someone from the psc wants to tweet with otb accounts, feel free to contact me to get login/pwd [16:13] <grizonnetm> something to have in mind about the PSC [16:13] <grizonnetm> msot of the job is to review and vote RFCs [16:14] <grizonnetm> for the last release there were 18 RFCs to vote in 3 months [16:14] <grizonnetm> it's quite a lot for someone not working on OTB on a daily basis [16:15] <jmichel> agreed [16:16] <grizonnetm> don't know what we can do about it [16:16] <grizonnetm> less RFCs? [16:17] <grizonnetm> do not require a formal vote for all modifications? [16:17] <gpasero> having more people would allow to share the job [16:17] <jmichel> more releases ;) while we are fixing bugs we are not rfcing ;) [16:17] <gpasero> I would keep the same RFC process [16:18] <rkm> can we take turn on reviewing code on atleast on a weekly basis to ease rfc changes [16:18] <rkm> ? [16:18] <VictorPoughon> gpasero is right. The current PSC constitution is built to avoid this "too much workload" problem, but that's only if we have more members... [16:18] <rkm> @girzonnetm: what is ossim in otb? [16:20] <grizonnetm> so I should not have resign and we should ask Jordi to not resign also even if he can't follow all RFCs [16:20] <gpasero> On the RFC side, I don't think there is much to do, just avoiding too large RFCs [16:21] <gpasero> we need only +3 on each RFC, PSC members can focus on the RFCs they want to merge [16:21] <grizonnetm> @rkm: ossim in otb was related to osgeo4w and issue with otb integration (which is related to ossim AFAIK), not important [16:22] <jmichel> grizonnetm: clear that there are not enough people [16:22] <gpasero> PSC members doing OTB on a daily basis will be able to review more RFC, and make sure the RFC are not left unvoted [16:22] <jmichel> and resining definitively does not help [16:22] <grizonnetm> ok so lets do this [16:23] <grizonnetm> I can also reply to Jordi on otb-developers and try to convince him to come back [16:24] <VictorPoughon> the things is that we said "please vote on this", "please vote on that" all the time. Should it be acceptable to be an idle PSC member? [16:26] <grizonnetm> fine for me [16:26] <grizonnetm> something else to add? [16:27] <grizonnetm> next topic? [16:27] <gpasero> yes [16:27] <grizonnetm> What to do next ? [16:28] <grizonnetm> What to do next in OTB 5.10/6.0/5.55? [16:28] <VictorPoughon> more apps! [16:28] <jmichel> unsupervised learning [16:28] <VictorPoughon> https://wiki.orfeo-toolbox.org/index.php/Wishlist [16:29] <gpasero> finishing SAR sensor migration would be also a good thing [16:29] <jmichel> feedback from TSX, it will be expensive ... [16:30] <grizonnetm> can perhaps merge TSX without supporting GRD [16:30] <jmichel> wishlist is a good roadmpa [16:31] <grizonnetm> in this case there is not much to do to finalize tsx [16:34] <grizonnetm> related to otb 6.0 we've perhaps to keep in mind the upcoming end of support for Qt 4 and also Python 2.x (not sure) [16:34] <grizonnetm> more related to OTB backend and not new features [16:34] <gpasero> +1, the backend has to evolve [16:35] <gpasero> but there are also small feature with good visibility I think [16:35] <grizonnetm> It's the 2 first major features that will be added for instance in QGIS 3 which will be release in 2017 (Spring) [16:37] <grizonnetm> I'll add a "backend" section to the wish list if it's ok [16:38] <VictorPoughon> yes of course [16:38] <grizonnetm> something else to discuss? [16:39] <VictorPoughon> not for me [16:39] <VictorPoughon> there is rkm point about compiler support [16:39] <VictorPoughon> rkm: can you clarify your question please? [16:41] <rkm> yes. but do you want to have disucssion now or next irc? [16:42] <grizonnetm> now [16:42] <rkm> it is about what compilers we are going to support in otb. so that we don't need to maintain them anymore [16:42] <rkm> it is also to state where we stand on c++11 and other stuff [16:43] <rkm> for instance, we need to make two packages from linux one with gcc4.x and other with gcc5/gcc6 [16:43] <VictorPoughon> what? [16:43] <rkm> that is related to shark. [16:44] <rkm> current packages run from centos5 to fedora 25, debian -sid without problems [16:44] <VictorPoughon> but why two packages? users only want one... [16:45] <rkm> adding shark with c++11 will break that. so during disucssion with julien about that, we decided to make two of them for users. but unfortunately due to issue in debian-sid vm that didn't worked [16:45] <rkm> there is one with shark (c++11) and one without [16:46] <rkm> current gcc 4.1.2 has proven to be greater compatibility with users. (most places it just works) [16:46] <rkm> that is because they depend on lower version of libc (on centos5) [16:46] <VictorPoughon> well that's crazy [16:47] <rkm> if I rebuild with recent gcc6, then those packages won't work on older systems. older here includes debian-stable, and ubuntu LTS [16:47] <VictorPoughon> ok then no shark in standalone packages [16:47] <rkm> work on packaging side is close to nothing. because we are just building on a different compiler [16:48] <VictorPoughon> humm ok then [16:48] <rkm> the question is matter of which compiler do we support [16:48] <grizonnetm> and if you rebuild with gcc 5? [16:48] <VictorPoughon> my concern is to minize maintenance work, but if you say it's minimal that's fine for me [16:48] <rkm> in my personal opinion: we can provide xdk on gcc6 (yes 6!) and binary packages with gcc 4.1.2 [16:49] <rkm> that is xdk is very cutting edge and packages are working as usual. [16:49] <rkm> but that is my personal view. it is yet to decide we take which route [16:49] <grizonnetm> there are 2 different questions: compilers OTB is supporting and compilers supported by OTB standalone package [16:49] <rkm> binary pakages cannot be rebuild with gcc5 [16:50] <rkm> package problem is the first part. compilers otb is supporting [16:51] <rkm> package on user side does not need a gcc compiler. it is just gcc runtime. as we build on a older machine. users don't have problem. [16:51] <VictorPoughon> what is your question to the PSC? [16:52] <rkm> what is psc's plan on the version of supported compilers? are we going to move to cxx11 compiler for packaging and dropping gcc < 4.8 [16:53] <rkm> do we plan to keep 4.1.2 or ask all users to have system with gcc5 or gcc6 runtime to use otb packages. [16:53] <rkm> based on that decision, only left is to make the switch on my side. [16:54] <rkm> also wheather we mantain two packages for linux [16:54] <gpasero> I think we should provide default packages that contain full OTB features, so it means dropping gcc 4.8 [16:54] <gpasero> gcc < 4.8 sorry [16:55] <VictorPoughon> I see. well it seems minimal to support the default gcc shippped with debian stable, ubuntu TLS, etc. For packaging side, I would say keep only 1 linux package, use the most recent gcc that works without issues everywhere. If that doesn't allow shipping shark in standalone package, then don't ship it, and only ship it in XDK [16:55] <VictorPoughon> gpasero: well that's a good point also [16:56] <grizonnetm> I personally agree to move to cxx11 compiler for packaging (which does not mean that cxx11 is mandatory to compile otb) [16:59] <grizonnetm> agree also with Guillaume about the fact that the standalone package should contain full otb features [16:59] <grizonnetm> so, do we have a plan? [16:59] <rkm> not yet [16:59] <rkm> either full otb features or better compatibility [17:00] <rkm> can't have both [17:00] <rkm> or two packages. [17:00] <gpasero> we can ensure that core OTB stays compatible with old compilers [17:00] <rkm> one package with full features enabled and with compatiblity is near to impossible [17:01] <rkm> or package libc and stdc++ (needs some work) [17:02] <gpasero> we can produce "compatibility packages" only if there is a demand on user side [17:02] <grizonnetm> +1 [17:03] <jmichel> So we are going to do training sessions with packages that do not support ubuntu LTS and debian stable ? [17:03] <jmichel> good luck with that [17:03] <VictorPoughon> jmichel: +1 [17:03] <jmichel> My experience is that I a trainee is on linux, she is on an old ubuntu [17:03] <VictorPoughon> the real problem here is shark no? [17:03] <jmichel> or she already compiled OTB by herself [17:03] <jmichel> so drop shark for packages [17:03] <rkm> this is why i propose xdk with better gcc6 [17:04] <rkm> so shark is only 10 mins away with ninja build [17:04] <jmichel> I can live with taht [17:04] <gpasero> gcc 4.8 is not enough for linux packages ? [17:04] <rkm> cd /tmp/build ; ninja OTBAppClassification-all [17:05] <jmichel> ok so that's settled then ? [17:05] <jmichel> no shark in default package, user that want shark can use xdk ? [17:05] <rkm> okay. so xdk drops gcc < 4.8 and package uses gcc 4.1.2 okay? [17:06] <VictorPoughon> +1 [17:06] <grizonnetm> ok [17:06] <grizonnetm> let's stop here? [17:06] <VictorPoughon> yes thank you all [17:06] == VictorPoughon [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has quit [Quit: Page closed] [17:07] <grizonnetm> thanks [17:07] <jmichel> thanks [17:07] <grizonnetm> A first version of decisions and summary is available on the wiki (feel free to complete) [17:07] <grizonnetm> I'll add the minutes soon*
