View source for IRC logs of friday 2016.01.08 2:30 PM CEST

[14:38] == jmichel [c2c7ac21@gateway/web/freenode/ip.194.199.172.33] has joined #otb
<br>[14:38] <grizonnetm> hi there
<br>[14:38] <jmichel> hi all
<br>[14:39] <GuillaumeP> Julien and Victor will join soon I guess
<br>[14:39] <jmichel> sorry to be late
<br>[14:39] <VictorPoughon> I'm here. Hello everyone.
<br>[14:39] <GuillaumeP> hi
<br>[14:39] <inglada> Who is the MC?
<br>[14:40] <inglada> Guillaume? Victor? You have proposed the agenda ...
<br>[14:40] <GuillaumeP> Sure , I can do the MC
<br>[14:41] <GuillaumeP> Quick reminder of the agenda :
<br>[14:41] <GuillaumeP> * Small debrief on previous release, organized around the following topics
<br>[14:41] <GuillaumeP> *  Setup a roadmap towards OTB 5.4
<br>[14:42] <GuillaumeP> I planned to spend around 1h on each
<br>[14:42] <GuillaumeP> We'll see how it goes
<br>[14:42] <GuillaumeP> First of all, I don't know if everyone know everyone ?
<br>[14:43] <GuillaumeP> clardeux ?
<br>[14:44] <clardeux> I am Cédric Lardeux from ONF International and I am working on forest mapping and I know CNES people, mainly Jordi, Manuel Julien
<br>[14:44] <GuillaumeP> ok, nice to meet you
<br>[14:44] <clardeux> but not the other. I am here more to see the discussion an also to suggest some thing from ONFI point of view
<br>[14:45] <clardeux> Nice to meet you also
<br>[14:45] <clardeux> french company to finish but work at international
<br>[14:45] <Christophe-CS> Christophe Palmann from CS-SI, I joined the OTB team 2 y ago
<br>[14:46] <GuillaumeP> Guillaume Pasero from CS-SI  OTB dev team
<br>[14:46] <VictorPoughon> I can also introduce myself. I'm Victor Poughon, recently joined CNES to work alongside jmichel and grizonnetm and OTB team
<br>[14:47] <GuillaumeP> Ok, let's begin, item 1 for debriefing : PSC and decision process
<br>[14:47] <GuillaumeP> We have tested this decision process during a full release, any comment ?
<br>[14:48] <grizonnetm> clearly helps to have structured the decision making process
<br>[14:48] <GuillaumeP> On my side, it has improved since the beginning
<br>[14:49] <grizonnetm> perhaps we're doing unnecessary RFC for 'small' things
<br>[14:49] <jmichel> I think everyone had to adjust at the beginning
<br>[14:49] <jmichel> but it has been running smoothly for a while now
<br>[14:49] <cresson> Rémi Cresson,new in PSC and "beta" release manager
<br>[14:49] <grizonnetm> but it is difficult to decide what requires an RFC
<br>[14:49] <cresson> (Irstea, french environmental agency)
<br>[14:50] <VictorPoughon> I agree, it's nice to have structure. However as a newcommer I don't really see the benefit of having two separate concepts for RFComments and RFChanges.
<br>[14:50] <grizonnetm> and last point for some RFC we're really missing a code review tool like gerrit
<br>[14:50] <GuillaumeP> agreed : some RfChange require a code review
<br>[14:51] <GuillaumeP>  > VictorPoughon : RFComments is for topics not mature yet for a RFChange
<br>[14:52] <GuillaumeP> Question : is gerrit necessary or can we simply tag RFCs needing review and assigning the review to somebody ?
<br>[14:52] <Christophe-CS> RFComments can also be viewed as a suggestion box
<br>[14:53] <jmichel> FYI, I started updating the PSC meeting wiki page : http://wiki.orfeo-toolbox.org/index.php/PSC_meetings#Friday_2016.01.08_2:30_PM_CEST
<br>[14:53] <grizonnetm> tags and review assignement are an option indeed
<br>[14:53] <jmichel> Guys, I feel like we should not change too many things for now
<br>[14:54] <VictorPoughon> jmichel: right.
<br>[14:54] <GuillaumeP> Same feeling here, gerrit can be a long quest
<br>[14:54] <jmichel> It's up and running. We can improve it over and over, but everytime there is a new adustment phase
<br>[14:54] <cresson> agreed
<br>[14:55] <jmichel> I would rather fine tune some of the roles and keep the RFC process untouched
<br>[14:55] <jmichel> but that's my point of view
<br>[14:56] <GuillaumeP> okay, maybe we can talk about the ReleaseManager role. Rémi : what is your feedback ?
<br>[14:56] <grizonnetm> jmichel: good point
<br>[14:57] <jmichel> GuillaumeP: exactly, I would like to hear from cresson
<br>[14:57] <cresson> honnestly, my impression is that It was easy mainlay because GuillaumeP did a great work
<br>[14:57] == grizonnetm [c2c7ac23@gateway/web/freenode/ip.194.199.172.35] has quit [Quit: Page closed]
<br>[14:58] == grizonnetm [c2c7ac21@gateway/web/freenode/ip.194.199.172.33] has joined #otb
<br>[14:58] <cresson> and I did not perform anything deep with git/dashboard/... but now I better understand the process
<br>[14:59] <GuillaumeP> The idea was also that the release manager is like a controler, not having to read every line of code
<br>[14:59] <cresson> I think we may have bypassed some stages like code review for remote modules
<br>[14:59] <jmichel> any recommandation on the role ?
<br>[15:00] <cresson> the wiki is very useful, it's very important for the role
<br>[15:01] <jmichel> I drafted the blog post, and I am therefore referenced as the author
<br>[15:01] <jmichel> but I think it would have been better that you appear as the author
<br>[15:01] <jmichel> something to note for next time
<br>[15:02] <jmichel> minor detail
<br>[15:02] <cresson> yes, but I did the RC1 one but as you wish
<br>[15:02] <GuillaumeP> Ok, anything more on "PSC and decision process" ?
<br>[15:03] <jmichel> maybe the release manager needs to be able to decide more things
<br>[15:03] <GuillaumeP> such as ?
<br>[15:03] <jmichel> like set the release date for instance
<br>[15:03] <jmichel> or the feature freeze date
<br>[15:04] <cresson> I found difficult to set a release date
<br>[15:04] <jmichel> I am under the impression that this release has been quite long, because we kept telling Remi "wait there's one more thing ..."
<br>[15:04] <VictorPoughon> jmichel: agreed. i would add responsibility of branches other than develop and feature branches
<br>[15:04] <jmichel> me first
<br>[15:04] <cresson> yes
<br>[15:05] <jmichel> who is the next release manager ?
<br>[15:05] <VictorPoughon> 5.2 shipped with too many problems IMO. Lack of testing? Pressure to release before end of the year?
<br>[15:05] <jmichel> but that is not on the RFC and release manager part
<br>[15:05] <jmichel> we missed things elsewhere
<br>[15:06] <cresson> at the begining the release date was planned to october, so I guess pressure to release before new year is a point
<br>[15:06] == pat_ [56c9b8dd@gateway/web/freenode/ip.86.201.184.221] has joined #otb
<br>[15:06] <jmichel> yes
<br>[15:06] == pat_ has changed nick to Guest94074
<br>[15:06] <jmichel> I think we should review the release strategy
<br>[15:06] <VictorPoughon> You're right. I mention it because the decision to delay the release what not made partly because it was not clear who should make it
<br>[15:07] <cresson> like I said I personaly find very difficult to tell dev team and others guys "release date will be XXXX)
<br>[15:07] <jmichel> first, the how to release is too long with risky tasks
<br>[15:07] <GuillaumeP> +1 for the long "how to release "
<br>[15:07] <grizonnetm> most issues in 5.2 are related to packaging stuffs
<br>[15:07] <VictorPoughon> It would make more sense if the release manager overviewed the release process, the release date and the git workflow together as a whole.
<br>[15:08] <jmichel> maybe we can ask the release manager to set a feature freeze date rather than a release date
<br>[15:08] <GuillaumeP> jmichel : you wanted to cast a vote for next RM ?
<br>[15:08] <cresson> I think this souhld be better
<br>[15:08] <inglada> Just a question about the release date.
<br>[15:09] <inglada> Do we do like Debian or like Ubuntu.
<br>[15:09] <inglada> That is : do we set a feature list or a deadline?
<br>[15:09] <inglada> Ship when ready or ship on a deadline?
<br>[15:09] <jmichel> for now it has more been like a feature list
<br>[15:09] <jmichel> but this is because there is roughly 6 months between each release
<br>[15:10] <jmichel> if we were able to release more often, pressure would not be so high
<br>[15:10] <inglada> so what are the criteria to decide that we can release?
<br>[15:10] <jmichel> It is feature list oriented : when all features that we planned to have are ready
<br>[15:11] <jmichel> but then comes a whole bunch of problems : superbuild updates, packaging ...
<br>[15:11] <jmichel> I think that is what delayed us in december
<br>[15:11] <inglada> Therefore, if there are systematic delays means that the feature list is too ambitious?
<br>[15:11] <GuillaumeP> I think we should keep it this way : it make consistent releases with new features every time
<br>[15:12] <inglada> Or that packaging process is not robust enough?
<br>[15:12] <jmichel> inglada: not sure. We keep adding items to the list ;)
<br>[15:12] <VictorPoughon> GuillaumeP: But with a deadline, or not?
<br>[15:12] <cresson> freeze date?
<br>[15:12] <grizonnetm> most RFCs have been merged in October
<br>[15:12] <inglada> jmichel: so the RM should be a dictator and say no more often
<br>[15:12] <rashadkm> some points regarding packaging,
<br>[15:12] <GuillaumeP> VictorPoughon: I would prefer a "target" date rather than a deadline
<br>[15:13] <rashadkm> there must be a test period of nightly generated packages and installers.
<br>[15:13] <jmichel> that was my point inglada
<br>[15:13] <GuillaumeP> inglada: packaging needs more anticipation
<br>[15:13] <VictorPoughon> Do we agree to make "speed up the release process" an objective for next realease and see how it goes then? We can decide for the one after that to switch to ubuntu style release if it goes well. This is also releated to packaging which we'll talk about next.
<br>[15:13] <rashadkm> for now,we just copy yesterday's build. but we should actually copy the build after code freeze
<br>[15:13] <inglada> rashadkm: can't packages and installers be tested more often?
<br>[15:14] <jmichel> I think packaging is definitively an issue that causes a lot of delay
<br>[15:14] <cresson> We could decide to stop new RFC at a given date, and then really starting testing, packaging, ...
<br>[15:14] <rashadkm> and for remote modules. it is important to have the source cloned in the release archive.
<br>[15:14] <jmichel> and it is part of the how to release
<br>[15:14] <GuillaumeP> rashadkm  inglada : packaging comes next in the agenda :)
<br>[15:14] <VictorPoughon> cresson: Yes, but that prevents working on release X+1 while X is being released. (See train model)
<br>[15:15] <rashadkm> inglada: we usually do. but there might be something messes up last minute.
<br>[15:15] <jmichel> We discussed with Manuel and Victor, and we have something to propose : remove from how to release all packaging stuff except what is really in our hands (self extracting binaries for linux and windows)
<br>[15:16] <jmichel> + plan the superbuild update sooner
<br>[15:16] <jmichel> with this we can release more often
<br>[15:16] <VictorPoughon> make distribution packaging asynchronous to OTB release basically
<br>[15:16] <GuillaumeP> +1 for early SuperBuild update
<br>[15:16] <GuillaumeP> and +1 for lighter release process
<br>[15:17] <inglada> instead of a target date for release, we should have a deadline for freeze and then start packaging etc. and release when ready
<br>[15:17] <jmichel> If we release every 3 months, we can work with a hard feature freeze deadline
<br>[15:17] <VictorPoughon> I'd like to apply to be next release manager
<br>[15:17] <jmichel> inglada: thing is we can not wait for all packages to be ready to release
<br>[15:18] <jmichel> because a lot of problems are not directly in our hands
<br>[15:18] <jmichel> this is what delayed us for 2 months
<br>[15:18] <inglada> jmichel: agreed. Packages for distros are out of the release process.
<br>[15:18] <jmichel> good
<br>[15:19] <VictorPoughon> GuillaumeP: where are we on the agenda?
<br>[15:19] <GuillaumeP> (ok, Victor registered candidate for RM, we'll cast votes later)
<br>[15:19] <GuillaumeP> now comes "Development workflow"
<br>[15:19] <jmichel> stop
<br>[15:19] <jmichel> can we just conclude on this point
<br>[15:20] <jmichel> summary : someone proposes a lighter how to release, without distro packaging stuff. We will try to release every 3 months, with a hard feature freeze deadline
<br>[15:20] <GuillaumeP> +1 for packaging out of release process
<br>[15:20] <VictorPoughon> good for me jmichel
<br>[15:21] <grizonnetm> we keep only packaging in our hands
<br>[15:21] <grizonnetm> synchro with the release process
<br>[15:21] <jmichel> RM has all power to decide to exclude features that are not ready and they will be in next release
<br>[15:21] <jmichel> ok, can someone take this how to release and get it on a diet ?
<br>[15:22] <VictorPoughon> jmichel: the next RM we vote today can overview this no?
<br>[15:22] <jmichel> ok
<br>[15:22] <jmichel> so everyone : release every 3 months will only work if making the release takes less than the current 2 months ;)
<br>[15:22] <jmichel> something to keep in mind
<br>[15:22] <VictorPoughon> :)
<br>[15:23] <VictorPoughon> How do minor releases fit into the 3 month cycle?
<br>[15:23] <GuillaumeP> do we keep time for bugfix before release ?
<br>[15:23] <VictorPoughon> GuillaumeP: Yes. RC and bug fix comes after feature freeze.
<br>[15:23] <grizonnetm> we don not have for now a "how to release" for bugfix version AFAIK
<br>[15:23] <jmichel> one sprint after feature freeze to prepare new release
<br>[15:24] <GuillaumeP> ok
<br>[15:24] <cresson> ok
<br>[15:24] <GuillaumeP> so feature freeze = RelCandidate, then 1 sprint of bugfix
<br>[15:24] <jmichel> btw, as soon as the feature freeze is announced, develop should be branched so that business can continue
<br>[15:24] <GuillaumeP> then release
<br>[15:25] <VictorPoughon> jmichel: yes, release branch is created.
<br>[15:25] <jmichel> not sure that feature freeze  = RC
<br>[15:25] <jmichel> but we can see later
<br>[15:25] <GuillaumeP> well, it would be faster
<br>[15:26] <VictorPoughon> So what has a deadline? feature freeze, RC or release?
<br>[15:26] <jmichel> maybe we do not need RC
<br>[15:26] <jmichel> ok let say feature freeze = RC
<br>[15:26] <nhv> usually feature freeze, fix all known issues, then RC
<br>[15:26] <VictorPoughon> jmichel: but what if some features are freezed but not complete?
<br>[15:26] <jmichel> +1 nhv
<br>[15:27] <jmichel> they are excluded from release
<br>[15:27] <jmichel> unless there is a consistent part of it that can be release
<br>[15:28] <VictorPoughon> jmichel: ok. So it's not "all ongoing RFC should be in next realease". It's "next release will only include features ready to ship today".
<br>[15:28] <VictorPoughon> correct?
<br>[15:28] <jmichel> yes
<br>[15:28] <VictorPoughon> ok
<br>[15:28] <jmichel> every one ok with this ?*
<br>[15:28] <inglada> yes
<br>[15:28] <cresson> yes
<br>[15:29] <VictorPoughon> yes
<br>[15:29] <nhv> this is standard practice in mot projects that I know
<br>[15:29] <GuillaumeP> yes
<br>[15:29] <jmichel> good
<br>[15:29] <jmichel> we vote for RM ?
<br>[15:29] <GuillaumeP> +1 nhv, but is it applicable with a release every 3 months ?
<br>[15:30] <jmichel> GuillaumeP: I think so, if we can go one working on new feature while taking care of release
<br>[15:30] <nhv> most projects have release goals  goals can be pushed to later a release
<br>[15:30] <jmichel> the problem with current process is that everything stops during release
<br>[15:31] <VictorPoughon> As long as we have a good git workflow it should be doable
<br>[15:31] <VictorPoughon> some projects work on 3 release in parallel (develop, beta, rc) etc.
<br>[15:31] <nhv> there should be no need for everything to stop
<br>[15:32] <GuillaumeP> +1, our workflow allows to continue features even during release process
<br>[15:32] <GuillaumeP> so, time to vote for RM
<br>[15:32] == nhv [~chatzilla@2601:18e:c201:9f30:58ac:156b:2f8d:c450] has quit [Remote host closed the connection]
<br>[15:32] <GuillaumeP> I propose myself as backup RM
<br>[15:33] == nhv [~chatzilla@2601:18e:c201:9f30:d4c:7b70:ea85:162e] has joined #otb
<br>[15:33] <GuillaumeP> anyone else wants to try RM role?
<br>[15:34] <grizonnetm> +1 for Victor as RM and keeping a backup RM
<br>[15:34] <jmichel> +1
<br>[15:34] <GuillaumeP> +1
<br>[15:34] <Christophe-CS> +1
<br>[15:34] <cresson> +1
<br>[15:34] <inglada> +1
<br>[15:34] <jmichel> good, that at least was quick
<br>[15:34] <jmichel> ;)
<br>[15:35] <GuillaumeP> yes, I think we can move on
<br>[15:35] <GuillaumeP> "Development workflow"
<br>[15:35] <GuillaumeP> Git branches, bugfixes, ...
<br>[15:36] <jmichel> I would like to talk about the packaging manager role
<br>[15:36] <GuillaumeP> Introducing a new role ?
<br>[15:36] <jmichel> where is the agenda ?
<br>[15:37] <GuillaumeP> Small debrief on previous release, organized around the following topics :         PSC and decision process         Development workflow         Packaging strategy for Linux         Content and agenda for OTB 5.2.1      Setup a roadmap towards OTB 5.4         Gather people ideas to enhance the roadmap (Jordi already compiled a lot of ideas)         What is the status of QGIS integration and who is maintainer         Should ice be merge
<br>[15:37] <VictorPoughon> GuillaumeP: can you clarify agenda and current topic please?
<br>[15:37] <GuillaumeP> We still are on the first topic
<br>[15:37] <GuillaumeP> "PSC and decision process"
<br>[15:37] <jmichel> ok but dev workflow I think we already discussed it
<br>[15:37] <jmichel> maybe there is more to say
<br>[15:38] <VictorPoughon> agenda: https://gist.github.com/vpoughon/aa9a4cee465d7b48d6c6
<br>[15:38] <GuillaumeP> If you want to introduce a new role, this can be done in this topic
<br>[15:38] <GuillaumeP> "Development workflow" will go fast if every one is satisfied
<br>[15:39] <GuillaumeP> Is your role linked with the Linux packaging coming after ?
<br>[15:39] <VictorPoughon> Regarding workflow I don't understand the purpose of our master branch. Are release branches merged into master? If yes the graphic on the wiki is out of date
<br>[15:39] <jmichel> GuillaumeP: yes, lets wait for next point
<br>[15:40] <GuillaumeP> Ok, let's talk about master branch
<br>[15:40] <GuillaumeP> the release branches are not merged into master
<br>[15:41] <GuillaumeP> release branches are for long term maintainance and minor releases
<br>[15:42] <GuillaumeP> master branch keeps track of the last major release
<br>[15:42] <VictorPoughon> GuillaumeP: Isn't that the corresponding release branch?
<br>[15:42] <GuillaumeP> (not major release, X.Y.0 releases
<br>[15:43] <VictorPoughon> The issue I have is that if maintenance fixes are not merged into master, then we track of "bad" code states. And worst of all in the default branch.
<br>[15:43] <GuillaumeP> on release branch 'release_5.2' you find the released version 5.2.0 + all bugfixes that affected 5.2.0
<br>[15:43] <VictorPoughon> So master branch is lastest release without fixes? What is the point of that?
<br>[15:44] <clardeux> I will be connected but I need to leave you Sorry. Jordi will give my feature request if necessary. Best
<br>[15:44] <VictorPoughon> clardeux: see you
<br>[15:44] <inglada> clardeux: no problem
<br>[15:44] <grizonnetm> quote of our wiki page on git workflow "master : branch which contains the released code with the version tag, it can be considered a fairly stable branch. It contains the latest release."
<br>[15:45] <GuillaumeP> VictorPoughon: if you add bugfixes in master branch, they won't be version specific
<br>[15:45] <jmichel> why not simply removing master branch ?
<br>[15:46] <VictorPoughon> So users who 'git clone' master get a potentially buged version?
<br>[15:46] <GuillaumeP> because this is the default branch most users are used to see
<br>[15:46] <jmichel> in this case it should correspond to the best stable version, i.e. with bugfixes
<br>[15:47] <GuillaumeP> Let see this with a different view : having a master branch doesn't cost a thing
<br>[15:47] <VictorPoughon> Either (1) delete master or (2) merge lastest release into it or (3) change nothing. Shall we vote?
<br>[15:47] <inglada> I vote 2
<br>[15:47] <VictorPoughon> I vote 2
<br>[15:47] <GuillaumeP> I vote 3
<br>[15:48] <inglada> because if it is a release we hope it is stable
<br>[15:48] <VictorPoughon> (i'm not in PSC so my vote is just opinion I guess)
<br>[15:48] <jmichel> I vote 2 because I do not understand the role of master branch in its current state
<br>[15:48] <GuillaumeP> I fear that adding bugfix in master will make the next merge develop->master more difficult
<br>[15:49] <VictorPoughon> (Sorry GuillaumeP just trying to move the meeting forward)
<br>[15:49] <inglada> aren't bugfixes merged in develop
<br>[15:49] <jmichel> i think so
<br>[15:49] <GuillaumeP> Yes,
<br>[15:50] <inglada> I don't understand the problem GuillaumeP
<br>[15:51] <GuillaumeP> I don't have a clear view of what could happen, so I'll think about it after the meeting
<br>[15:51] <inglada> but I propose to move on, because I would like that we address features for 5.4
<br>[15:51] <GuillaumeP> Sure
<br>[15:51] <VictorPoughon> we can also vote on otb-developers
<br>[15:51] <inglada> packaging?
<br>[15:51] <grizonnetm> vote 2 but if I understand master = alias to last stable branch
<br>[15:51] <GuillaumeP> Yes : Packaging (for Linux)
<br>[15:51] <grizonnetm> ok next opic
<br>[15:51] <jmichel> for now packaging is a bit messy
<br>[15:51] <cresson> huh
<br>[15:51] <jmichel> because we do not have a strategy and someone to enforce it
<br>[15:52] <jmichel> so we are working in parallel on all issues with all packaging targets
<br>[15:53] <jmichel> I propose that : 1) only self contained packages are produced at release time 2) A packaging manager is responsible for setting priorities between packages target
<br>[15:54] <GuillaumeP> +1
<br>[15:54] <inglada> what are 1 and 2?
<br>[15:54] <inglada> 1 = windows and linux binaries?
<br>[15:54] <GuillaumeP> could you detail on the packaging manager
<br>[15:54] <VictorPoughon> Do the responsabilities of the packaging manager include self-contained packaging or only distribution packages (debian, etc...)
<br>[15:54] <inglada> 2 = rpm, deb?
<br>[15:55] <jmichel> inglada: yes
<br>[15:55] <jmichel> that is actually what we decided earlier : at release time, only build packages that we can build entirely on our own
<br>[15:55] <inglada> if self-contained is part of release, they should be on the dashboard?
<br>[15:55] <jmichel> inglada: yes
<br>[15:55] <VictorPoughon> yes
<br>[15:56] <VictorPoughon> Any candidates for packaging manager?
<br>[15:56] <cresson> not me...
<br>[15:56] <inglada> and distro packages can be synched with distros releases?
<br>[15:57] <jmichel> inglada: maybe. but there is also osgeo4w, + mac things and co
<br>[15:57] <inglada> who has been doing most of packaging work util now? rashadkm?
<br>[15:58] <VictorPoughon> Can we open a thread for nominating a package manager on the list and move to next item on agenda?
<br>[15:58] <inglada> OK
<br>[15:58] <jmichel> ok
<br>[15:58] <rashadkm> i was doing debian for a while.
<br>[15:58] <GuillaumeP> ok
<br>[15:58] <inglada> 5.2.1?
<br>[15:59] <GuillaumeP> yes, minor release:  do we plan it ?
<br>[15:59] <jmichel> we need to get the new version of ossim that fixes things in superbuild
<br>[15:59] <inglada> still useful if we decide a 3 month cycle?
<br>[15:59] <jmichel> yes
<br>[15:59] <inglada> can we limit 5.2.1 to that?
<br>[15:59] <jmichel> no : fix the bug of no apps in monteverdi on windows
<br>[15:59] <VictorPoughon> inglada: I would add fix the monteverdi windows installer
<br>[15:59] <jmichel> which sadly traces back to OTB sources
<br>[16:00] <GuillaumeP> I would limit to current known issues + Ossim update in SuperBuild
<br>[16:00] <jmichel> so these two things
<br>[16:00] <inglada> OK, so 5.2.1 can be released next week ;)
<br>[16:00] <jmichel> VictorPoughon: can you propose a how to for minro release ?
<br>[16:00] <VictorPoughon> jmichel: will do
<br>[16:01] <jmichel> inglada: yes, it should be fast, otherwise there is no point
<br>[16:01] <jmichel> ok, so VictorPoughon is in charge of managing this minor release as well, if that is ok for everyone
<br>[16:01] <inglada> +1
<br>[16:01] <GuillaumeP> ok, 5.2.1 target for end of next week
<br>[16:01] <VictorPoughon> Yes.
<br>[16:02] <GuillaumeP> Next topic ?
<br>[16:02] <cresson> ok
<br>[16:02] <grizonnetm> k
<br>[16:02] <inglada> 5.4?
<br>[16:02] <GuillaumeP> Roadmap for 5.4
<br>[16:02] <jmichel> let's go
<br>[16:02] <inglada> I dumped some ideas here http://wiki.orfeo-toolbox.org/index.php/PSC_meetings#Features_for_next_release
<br>[16:03] <inglada> from what I gathered over the last few months
<br>[16:03] <inglada> surely incomplete and even wrong, but may be a start
<br>[16:03] == Guest94074 [56c9b8dd@gateway/web/freenode/ip.86.201.184.221] has quit [Ping timeout: 252 seconds]
<br>[16:04] <inglada> I you agree, I suggest starting by removing things
<br>[16:04] <jmichel> ;)
<br>[16:04] <GuillaumeP> on your list : item 1 : I would start with "Integrate Shark",  then remove OpenCV for release 5.6
<br>[16:04] <jmichel> I would like to add two things:
<br>[16:04] <jmichel> greener dashboard, or even green dasbhoard
<br>[16:05] <jmichel> and Pierre's code on large scale random forests
<br>[16:05] <GuillaumeP> +1 for green dashboard
<br>[16:05] <grizonnetm> +1 greenwashing
<br>[16:05] <VictorPoughon> +1
<br>[16:05] <cresson> +1
<br>[16:05] <jmichel> but that is not a feature ;)
<br>[16:05] <cresson> What is large scale random forest?
<br>[16:05] <grizonnetm> it's a bug
<br>[16:06] <jmichel> a scalable random forest algorithm developed by a former phd
<br>[16:06] <cresson> nice
<br>[16:07] <inglada> what do we remove (remember, release in 3 months)
<br>[16:08] <cresson> inglada, from your list?
<br>[16:08] <jmichel> I would do it the other way : who wants to do what ?
<br>[16:08] <inglada> cresson: yes
<br>[16:09] <Christophe-CS> what is "DTW from CNES study" ?
<br>[16:09] <cresson> inglada, the parallel stuff (MPI) may be delayed (Will have time later to bring this)
<br>[16:09] <jmichel> Dynamic Time Warping distances between time series
<br>[16:09] <inglada> jmichel: let's face it, most of it will be done under CNES contract
<br>[16:09] <inglada> jmichel: remove DTW?
<br>[16:10] <GuillaumeP> remove C++11/14, it can be used in remote modules
<br>[16:11] <jmichel> inglada: not necessarily. We also do things directly here at cnes, or through other contracts. And others can participate.
<br>[16:11] <inglada> c++11/14 needs a discussion : do we agree in not supporting old compilers? but this out of topic fir this meeting I guess
<br>[16:12] <inglada> jmichel: I mean that not only "who wants to do what", but also "who funds what"
<br>[16:13] <GuillaumeP> inglada: I don't believe c++11/14 is necessary for OTB right now
<br>[16:13] <VictorPoughon> Let's not talk about C++11 now...
<br>[16:14] <inglada> DTW? what did you mean jmichel?
<br>[16:14] <jmichel> I was answering a question from Christophe-CS
<br>[16:15] <jmichel> with cnes contract, we can for instance work on 12, green dashboard and maybe large scale RF
<br>[16:15] <jmichel> this is already a lot for 3 month (but 12 can be adjusted)
<br>[16:16] <inglada> Shark: I started using it here, but will can't commit to do the integration. I can help a bit, but not much.
<br>[16:16] <jmichel> I think it is interesting, and probably requires some work. Would you rather have it or have large scale Random Forest ?
<br>[16:17] == grizonnetm [c2c7ac21@gateway/web/freenode/ip.194.199.172.33] has quit [Ping timeout: 252 seconds]
<br>[16:18] <inglada> 2 different purposes : Shark offers new algorithms we don't have and can fully replace OpenCV. It also uses OpenMP for parallel learning.
<br>[16:18] <jmichel> then there are some smaller things like 6 or 4
<br>[16:18] <GuillaumeP> jmichel: by 12, you refer to c++11 ? the numbering changed
<br>[16:18] <jmichel> I meant 16
<br>[16:18] <jmichel> if we could stop changing numbering it would help ;)
<br>[16:19] <GuillaumeP> right :)
<br>[16:19] <inglada> Sorry, I was editing the page
<br>[16:19] <jmichel> so smaller things are 10 and 8
<br>[16:20] <inglada> yes, let's keep 8 and 10
<br>[16:20] <inglada> 11 is also small (grizonnetm can confirm)
<br>[16:21] <jmichel> 5 we are working on here at cnes but I doubt something will be ready in 3 months
<br>[16:21] <inglada> what about 6?
<br>[16:22] <jmichel> also small
<br>[16:22] <jmichel> we can do a remote module with what already exists
<br>[16:22] <jmichel> if we want to do advanced interferometry there is more work
<br>[16:22] <inglada> what is advanced interferometry?
<br>[16:23] <jmichel> phase unrolling and co ?
<br>[16:23] <inglada> OK
<br>[16:23] <jmichel> I mean 10 and 8 is just a matter of writing apps
<br>[16:24] <jmichel> 6 is writing a module
<br>[16:24] <inglada> what about 7 to complete the SAR part done for 5.2?
<br>[16:24] <Christophe-CS> +1 for 7
<br>[16:24] <inglada> 17? jmichel?
<br>[16:24] <jmichel> well, I feel that the number of speckle filters is already higher than the number of SAR users ;)
<br>[16:25] <jmichel> just joking
<br>[16:25] <Christophe-CS> we have a bigger set of filters since last release, but nothing for polarimetric data
<br>[16:25] <VictorPoughon> I have begun work on 16
<br>[16:25] <jmichel> There are people here at cnes working with SAR data and OTB, why not asking them if something is missing on this side ?
<br>[16:25] <inglada> clardeux explicitly said to me that he would prefer more filters for mono pol than for multi-pol
<br>[16:26] <inglada> I guess sigma-Lee and gamma-MAP is not much work (less than polarimetric filters with wishart distributions)
<br>[16:26] <cresson> [back in 10]
<br>[16:27] <Christophe-CS> FYI, there is this RFC : http://wiki.orfeo-toolbox.org/index.php/Requests_for_Comments-13:_Next_changes_about_SAR_image_processing
<br>[16:27] <inglada> VictorPoughon: you mean 16.1 or all 16?
<br>[16:27] <jmichel> yes but in the frame of cnes contract, I do not feel like spending another 1 dev / 3 months on speckle filtering ...
<br>[16:28] <inglada> jmichel: OK, this is what I meant by "who does" vs "who funds". I understand!
<br>[16:28] <jmichel> If there is one important thing missing, we can do it
<br>[16:28] <Christophe-CS> ... and also this mess. on the otb users list : https://groups.google.com/forum/#!topic/otb-users/ZzEIz-U8yco
<br>[16:29] <VictorPoughon> inglada: 16.1 definitly (refactoring into filters) 16.2 depends what you mean
<br>[16:30] <inglada> 16.2 is generating new samples from existing ones when there is few reference data. needs some R&D IMO
<br>[16:30] <VictorPoughon> inglada: ok then no
<br>[16:31] <inglada> 14?
<br>[16:31] <VictorPoughon> I'll share my work with RFC soon (was waiting for after 5.2 release)
<br>[16:31] <jmichel> 14 is a big one
<br>[16:31] <jmichel> but I think we need 16.1 first
<br>[16:31] <GuillaumeP> inglada: seems a big one, we need to split it
<br>[16:32] <jmichel> it is related
<br>[16:32] <inglada> jmichel: yes
<br>[16:32] <VictorPoughon> So 16.1 for 5.4, 14 for later?
<br>[16:32] <jmichel> I think so
<br>[16:32] <inglada> wiki updated ;)
<br>[16:32] <jmichel> anyway, these are a lot of things for 5.4 already
<br>[16:33] <inglada> therfore, 13 is out too?
<br>[16:33] <jmichel> yes
<br>[16:33] <GuillaumeP> yes, not enough details
<br>[16:34] <jmichel> 18 we have the filter, not the app
<br>[16:34] <inglada> Will leave in 5 minutes.
<br>[16:34] <jmichel> ok
<br>[16:34] <VictorPoughon> next topic?
<br>[16:35] <inglada> If I have to choose, I take 3 and leave 2 for later
<br>[16:35] <GuillaumeP> wait, should we conclude on the priority list ?
<br>[16:35] <jmichel> ok I think 1 is mandatory to have shorter release cycles
<br>[16:36] <VictorPoughon> 2 is out, no?
<br>[16:36] <jmichel> so 1, 3, 16.1 is already a good target
<br>[16:36] <inglada> I understand that we can do: 3, 6, 8, 10, 11, 16.1
<br>[16:36] <jmichel> we can add some of the smaller things if there is room left
<br>[16:36] <jmichel> but we should start with big things first
<br>[16:37] <inglada> 16.1 first
<br>[16:37] <inglada> ?
<br>[16:37] <VictorPoughon> fine for me
<br>[16:38] <jmichel> I think that with cnes contract we can start 1, 3 and 16.1 together
<br>[16:39] <VictorPoughon> ok so: 1, 3, 16.1 (cnes) and 6, 8, 10, 11 ?
<br>[16:39] <inglada> Leaving. Thank you all.
<br>[16:39] <GuillaumeP> Bye
<br>[16:39] <jmichel> ++
<br>[16:39] <VictorPoughon> inglada: bye bye
<br>[16:39] <cresson> +
<br>[16:39] <Christophe-CS> bye
<br>[16:39] <VictorPoughon> ok so next topic maybe?
<br>[16:40] <VictorPoughon> before everyone leave?
<br>[16:40] <jmichel> yes we have a roadmap for next release
<br>[16:40] <jmichel> maybe to ambitious, we'll see
<br>[16:40] <GuillaumeP> Qgis integration !
<br>[16:40] <GuillaumeP> and Ice
<br>[16:40] <GuillaumeP> which one first ?
<br>[16:40] <jmichel> Qgis
<br>[16:41] <jmichel> same unresolved question : who is maintaining qgis access to application ?
<br>[16:41] <jmichel> and is it maintained ?
<br>[16:41] <rashadkm> should we really need to keep qgis as a part of otb?
<br>[16:42] <cresson> rashadkm, what do you mean by part of it?
<br>[16:42] <jmichel> I would say that the problem is that the qgis integation is not really a part of otb ;)
<br>[16:42] <rashadkm> i mean maintenance and stuff.
<br>[16:42] <GuillaumeP> I miss some information, but I remember that some people at CS worked on the processing plugin for QGis
<br>[16:42] <jmichel> GuillaumeP: yes, one shot work has been done
<br>[16:43] <GuillaumeP> for the moment, no one taking care of it
<br>[16:43] <jmichel> but I mean tracking bugs, answering questions, testing
<br>[16:43] <rashadkm> either someone in otb team must work with qgis and track changes along with otb and qgis releases.. or simply don't care of that part.
<br>[16:43] <jmichel> rashadkm: things is users come to otb through this qgis thing. Then it does not work and for them it is otb that does not work
<br>[16:44] <cresson> jmichel, +1
<br>[16:44] <jmichel> so I think it is really our problem
<br>[16:44] == inglada [~user@pc-117-162.ups-tlse.fr] has quit [Ping timeout: 250 seconds]
<br>[16:44] <rashadkm> it might be sometimes otb not packed well with qgis
<br>[16:44] <jmichel> rashadkm: yes absolutely
<br>[16:45] <jmichel> but conclusion is the same
<br>[16:45] <rashadkm> so the problem is packaging by qgis team.
<br>[16:45] <rashadkm> who create otb plugin
<br>[16:45] <jmichel> CS I think
<br>[16:45] <rashadkm> to really really fix this. someone in otb should take in charge of this plugin.
<br>[16:46] <GuillaumeP> Processing plugin is maintained by AlexBruy
<br>[16:46] <GuillaumeP> https://plugins.qgis.org/plugins/processing/
<br>[16:46] <GuillaumeP> is it the one where OTB is packaged ?
<br>[16:47] <cresson> Is it the old called "sextante toolbox?"
<br>[16:47] <kalxas> Victor Olaya is the processing maintainer
<br>[16:48] <kalxas> yes
<br>[16:48] <jmichel> I think that for every new release of OTB, we need to test and possibly update the otb part of this plugin
<br>[16:48] <jmichel> we can see this as a packaging stuff
<br>[16:49] <VictorPoughon> so async with release?
<br>[16:49] <jmichel> maybe
<br>[16:49] <GuillaumeP> application parameters may change
<br>[16:49] <jmichel> yes that is the problem
<br>[16:49] <GuillaumeP> so it is better to sync with releases
<br>[16:50] <VictorPoughon> if the qgis plugin is not ready, does that delay the release?
<br>[16:50] <jmichel> so actually this is not packaging
<br>[16:50] <jmichel> no because it does not impact otb sources, it has its own sources
<br>[16:50] <GuillaumeP> it is Qgis interfacing
<br>[16:50] <jmichel> but those sources need to be updated for each release
<br>[16:51] <kalxas> things are a bit more complex: Processing plugin is now in QGIS core, which means most people will get an updated version on QGIS releases, not from plugin manager
<br>[16:51] <kalxas> so updating the plugin does not always solve the issue
<br>[16:51] <rashadkm> otb is accessible in qgis through sextante pluigin. if sextante plugin is managed by V.oyala and otb part by AlexB
<br>[16:51] <kalxas> there was the same issue with grass7
<br>[16:51] <rashadkm> how does that play for us with otb release.
<br>[16:52] <rashadkm> better for long run. but not easy. create a new plugin in otb qgis plugin. That can even use ice rendering engine.
<br>[16:52] <jmichel> does the plugin check for OTB version ?
<br>[16:53] <rashadkm> This plugin can be even a remote module tested on dashboard!
<br>[16:54] <jmichel> if the problem is that the plugin gets out of sync with otb version, it should simply check otb version and only accept to work with the right version
<br>[16:54] <jmichel> then the problem is solved
<br>[16:54] <GuillaumeP> indeed, version checking seems necessary
<br>[16:54] <VictorPoughon> jmichel: that could work
<br>[16:54] <rashadkm> i don't think out of sync is the actual problem. both plugin and otb are updated together right?
<br>[16:55] <VictorPoughon> rashadkm: unclear at this point
<br>[16:55] <jmichel> rashadkm: yes, but what version is packaged ?
<br>[16:55] <jmichel> I mean, where is the OTB used by qgis ? is it always the correct version ?
<br>[16:55] <rashadkm> the plugin downloads, otb also right.
<br>[16:56] <rashadkm> this was case for one plugin here at cs
<br>[16:57] <VictorPoughon> Are we going to decide anything more about QGIS now? Can we open a QGIS plugin thread on the list?
<br>[16:57] <jmichel> yes VictorPoughon
<br>[16:57] <jmichel> lets move on
<br>[16:58] <GuillaumeP> Ok, next : Ice integration
<br>[16:58] <jmichel> this is a small one
<br>[16:58] <jmichel> Ice is currently a very small side project
<br>[16:58] <jmichel> but since it is a side project, it needs its own version number, packaging, documentation, dashboard ...
<br>[16:59] <jmichel> for me it makes more sense to have it inside OTB
<br>[16:59] <GuillaumeP> on this one, I actually changed my mind , mostly for the sake of packaging
<br>[16:59] <GuillaumeP> I agree, it would be easier to manage
<br>[16:59] <jmichel> we can have it inside, and deactivate all the new dependencies, we have that capability now
<br>[17:00] <jmichel> I can take care of this
<br>[17:00] <VictorPoughon> One option to consider is to merge after green dashboard, what do you think?
<br>[17:00] <VictorPoughon> Or is that irrelevant?
<br>[17:01] <jmichel> I do not think it is very risky for dashboard
<br>[17:01] <jmichel> it will be a new group of modules, and new modules, with very few links to existing modules
<br>[17:01] <VictorPoughon> ok
<br>[17:01] <jmichel> do we agree on this ?
<br>[17:01] <VictorPoughon> should the PSC vote or is it decided?
<br>[17:02] <jmichel> I prepare the branch, submit a RFC and then there will be a vote
<br>[17:02] <cresson> ok
<br>[17:02] <GuillaumeP> ok
<br>[17:02] <VictorPoughon> ok
<br>[17:02] <jmichel> I just do not want to do all the work if nobody agrees
<br>[17:02] <jmichel>  ;)
<br>[17:02] <GuillaumeP> it will be a +1 for me
<br>[17:02] <jmichel> ok good
<br>[17:02] <GuillaumeP> We already did the 2 last items
<br>[17:03] <jmichel> one more thing
<br>[17:03] <jmichel> I would like monteverdi to be fully managed by psc starting this release
<br>[17:03] <jmichel> and we need a roadmap for next release
<br>[17:03] <jmichel> but we can start a thread about this
<br>[17:04] <GuillaumeP> is the release manager the same ?
<br>[17:04] <GuillaumeP> ( I would say yes)
<br>[17:04] <jmichel> well, I almost suggested that monteverdi becomes a module ;)
<br>[17:04] <jmichel> but one step at a time ;)
<br>[17:06] <VictorPoughon> ok for me (as release manager)
<br>[17:06] <jmichel> Ok so will start a thread to discuss next features to develop in monteverdi
<br>[17:06] <GuillaumeP> Alright, the discussion on roadmap will start on dev-list
<br>[17:06] <jmichel> good
<br>[17:06] <jmichel> when is next meeting ? -> thread also
<br>[17:07] <GuillaumeP> Next meeting after 5.4 ?  in 3 months ?
<br>[17:07] <jmichel> ok
<br>[17:07] <VictorPoughon> ok
<br>[17:07] <jmichel> thanks everybody
<br>[17:07] <jmichel> sorry for our late arrival
<br>[17:08] <jmichel> will do better next time
<br>[17:08] <cresson> no problem
<br>[17:08] <jmichel> bye
<br>[17:08] <GuillaumeP> Thanks, bye bye
<br>[17:08] <Christophe-CS> bye
<br>[17:08] <cresson> +
<br>[17:08] <VictorPoughon> see you al