IRC logs of Monday 2015.09.14 2:00 PM CEST

From OTBWiki
Jump to: navigation, search

[14:00] <grizonnetm> lets start
[14:01] <jmichel-otb> ok
[14:01] <jmichel-otb> first topic is git workflow and release process (including release manager role)
[14:02] <jmichel-otb> I assume you all read the wiki page http://wiki.orfeo-toolbox.org/index.php/Git http://wiki.orfeo-toolbox.org/index.php/Release_planning
[14:02] <jmichel-otb> the situation now is not very satisfactory
[14:03] <jmichel-otb> we have a lot of feature branches
[14:03] <jmichel-otb> some of them are quite long
[14:03] <jmichel-otb> in the mean time, only develop branch is fully tested
[14:04] <jmichel-otb> so question is : what is the purpose of the develop branch
[14:04] <jmichel-otb> and when do we merge feature branches
[14:05] <inglada> The develop branch should be the official real time snapshot of OTB
[14:05] <jmichel-otb> ok so a kind of "ship it" branch
[14:06] <inglada> this is my understanding
[14:06] <grizonnetm> in my understanding of the gitflow
[14:06] <grizonnetm> develop == integration branch
[14:07] <inglada> agreed
[14:07] <inglada> but I guess not everybody should push to it
[14:07] <inglada> only the release manager, maybe
[14:08] <jmichel-otb> well we obviously need at least some kind of approval
[14:08] <grizonnetm> don't think that the release manager need to do the merge
[14:08] <msd> How you deal with bug and minor modification as typo / doc, you create a branch and wait the go of release manager ?
[14:08] <cresson> My question: what exactly are purposes of each feature branches? I mean what is inside, can you give us example?
[14:09] <jmichel-otb> commits related to a new feature
[14:09] <jmichel-otb> for instance all commits corresponding to enhancement of no data management are isolated in a branch
[14:10] <cresson> ok
[14:10] <cresson> but, sometimes this could overlap?
[14:10] <jmichel-otb> yes that is right
[14:10] <jmichel-otb> especially with long feature branches
[14:10] <cresson> What should be done in that case
[14:10] <cresson> ?
[14:11] <jmichel-otb> you can cherry-pick commits from other branches
[14:11] <inglada> make branches known asap
[14:11] <inglada> in order to avoid overlap
[14:12] <inglada> to answer msd's question and grizonnetm comment
[14:12] <jmichel-otb> make branches smaller, merge earlier would be good too
[14:12] <cresson> okay
[14:12] <rashad> one good with seperate small feature branch is the ease of review by the reviewer.
[14:13] <inglada> to answer msd's question and grizonnetm comment: maybe we don't need to wait for release manager approval to push, but someone has to take the responsibility of making sure develop is "ready to ship" as stated
[14:14] <jmichel-otb> ok
[14:14] <jmichel-otb> can we agree on a list of commits that can go directly to develop ?
[14:14] <inglada> typos
[14:14] <jmichel-otb> typos, warning fixes, compilation errors fixes
[14:14] <grizonnetm> warnings
[14:14] <inglada> comments
[14:14] <jmichel-otb> bugfixes ?
[14:14] <inglada> documentation
[14:14] <inglada> not bugfixes
[14:15] <msd> why not ?
[14:15] <gpasero> bugfixes should meet some requirements, like, preserve functional perimeter
[14:15] <inglada> OK, let me rephrase: not bugfixes which are traked, since they have a number and a branch should be created
[14:16] <jmichel-otb> ok
[14:16] <inglada> or maybe we should limit to small bugfixes (for some definition of small), but this is slippery territory
[14:16] <jmichel-otb> but isn't it too heavey to create a branch, fix the bug in a single commit, and wait for release approval to merge the branch ?
[14:17] <inglada> maybe
[14:17] <msd> it is my feeling: overflood the release manager
[14:17] <jmichel-otb> ok let's get back to bugfixes later
[14:17] <jmichel-otb> now the other side of the spectrum : what definitively goes to feature branches
[14:17] <inglada> features?
[14:18] <jmichel-otb> hahah ;) ok
[14:18] <jmichel-otb> changing cmake scripts ?
[14:18] <inglada> examples: regression, nodata,
[14:18] <msd> udpate the superbuild ?
[14:18] <inglada> cmake scripts are changed for different reasons (adding a feature, fixing a bug, but also infrastructure)
[14:19] <jmichel-otb> yes, I was thinking of the latter
[14:19] <jmichel-otb> upgrading cmake infra
[14:19] <inglada> feature even if we should reserve "feature" for real features
[14:20] <jmichel-otb> ok
[14:20] <jmichel-otb> so in a branch
[14:20] <inglada> there should maybe be branches for "infrastructure"
[14:20] <jmichel-otb> and code optimization ?
[14:21] <inglada> I guess the threshold for a branch is when there are things which add/change behaviour
[14:21] <inglada> optimization in branches, of course, since you have to measure and demonstrate the improvement
[14:21] <inglada> in theory ...
[14:22] <jmichel-otb> like this one : https://git.orfeo-toolbox.org/otb.git/commit/e56e5e7725c72036c1a58a1ff162b739a04c6f61
[14:22] <jmichel-otb> saves some calls to UpdateOutputInformation()
[14:22] <jmichel-otb> currently pushed directly in develop
[14:23] <inglada> you could argue that this is a small one ...
[14:23] <cresson> did "ENH" == enhancement?
[14:23] <grizonnetm> yes
[14:23] <jmichel-otb> ok should small things go to develop regardless of what their purpose is ?
[14:23] <inglada> I think it's going to be difficult to foresee all possible cases
[14:23] <cresson> are there currently some other tags?
[14:24] <inglada> but since git branches are cheap, why not use them as often as possible?
[14:24] <jmichel-otb> yes cresson http://wiki.orfeo-toolbox.org/index.php/Commit_message_flags
[14:24] <jmichel-otb> inglada: of course, but we have to remember : develop is what is really tested
[14:24] <cresson> thank you jmichel-otb
[14:24] <cresson> ok
[14:24] <jmichel-otb> I am worried about growing amount of untested code
[14:25] <inglada> If you create a branch you can always run an experimental
[14:25] <inglada> this could be a requirement for a branch to be merged in develop
[14:25] <jmichel-otb> I read somewhere that the secret of successful branching is actually merging back
[14:25] <inglada> can you explain?
[14:26] <jmichel-otb> inglada: we have a mean of testing branches on a nightly basis (see http://dash.orfeo-toolbox.org/buildSummary.php?buildid=199943)
[14:26] <cresson> what is branching back (sorry)
[14:26] <cresson> merging back
[14:26] <jmichel-otb> cresson: merge the feature branch back in develop branch
[14:27] <jmichel-otb> I think it means that if you only create new branches and never merge, you are in trouble
[14:27] <grizonnetm> I agree with jmichel
[14:27] <jmichel-otb> so I fully support doing a lot of branches
[14:27] <grizonnetm> my main concern is also overlap between branches
[14:27] <rashad> but these feature branches are only tested on single platform. what about other platforms? compilers? or simply a test under largeinput?
[14:27] <grizonnetm> which is already happening
[14:28] <jmichel-otb> but I would like to see an efficient merging process to deal with those branches
[14:28] <cresson> ook
[14:28] <inglada> someone has to be in charge of that, IMO
[14:28] <jmichel-otb> agreed
[14:28] <rashad> having two or three submission from other platforms at last minute might not look good
[14:29] <jmichel-otb> otherwise we merge all feature branches 2 weeks before the release candidate, and discover all the problem then
[14:29] <inglada> OK, what about this:
[14:30] <inglada> when the branch author has tested with an experimental, she requests for the merge, which is then tested in develop, then eventually develop is merged back with the feature so she can correct bugs?
[14:30] <inglada> maybe too complicated?
[14:31] <jmichel-otb> maybe but something like this
[14:31] <inglada> I mean that a branch can continue evolving after a first merge
[14:31] <inglada> with rebase, etc
[14:31] <jmichel-otb> actually you can require that develop is merged in the feature branch
[14:32] <jmichel-otb> of course
[14:32] <inglada> maybe rebase is cleaner
[14:32] <PhilippeML> usally before a pull request you rebase your feature branch on develop branch
[14:32] <jmichel-otb> only thing with rebase is that it changes history of public branches
[14:32] <jmichel-otb> yes PhilippeML I think this is the way
[14:33] <jmichel-otb> see the proposed checklist here http://wiki.orfeo-toolbox.org/index.php/Release_planning
[14:35] <gpasero> as stated before, smaller branches are merged faster and with less effort, it may be enough to ensure that develop branch evolves regularly
[14:35] <grizonnetm> as rebase changes the history, other projects seems to usually use git merge --no-ff
[14:36] <jmichel-otb> ok so if we have a release manager, she can check and accept merges of small branches regularly based on a checklist that we need to validate
[14:37] <jmichel-otb> do we agree on this ?
[14:37] <inglada> jmichel-otb: yes. And in general, small branches should be favored
[14:37] <jmichel-otb> rule of thumb
[14:37] <inglada> yes
[14:38] <inglada> And in any case, let's experiment for a while and point out what does not work
[14:38] <inglada> and build the rules from the experience
[14:38] <grizonnetm> +1
[14:38] <jmichel-otb> we already said that small, low impact commits can be done in develop : typo/comments/compilation warning and errors/dashboard fixes
[14:38] <jmichel-otb> ok
[14:38] <inglada> ok
[14:39] <jmichel-otb> I propose, following a comment from gpasero, that there is a backup release manager also
[14:39] <grizonnetm> ok and I think it should stay like this
[14:39] <jmichel-otb> who can step in if the rm is not responding, or assist her
[14:39] <grizonnetm> lets start to experiment the process with existing feature branches
[14:40] <inglada> who is the release manager?
[14:40] <jmichel-otb> not nominated yet
[14:40] <inglada> silence ...
[14:40] <jmichel-otb> cresson proposed himself
[14:40] <cresson> lol
[14:40] <inglada> OK. Candidates?
[14:40] <jmichel-otb> but I did not want to nominate someone before he fully understand what he commits to do
[14:40] <cresson> guys I am currently googling what git rebase is. I am afraid
[14:41] <grizonnetm> it would be good to have someone not from CNES/CS
[14:41] <jmichel-otb> in my view of the role, the rm do not do git operations homself
[14:41] <jmichel-otb> himself
[14:41] <jmichel-otb> only checks and formally approves merges
[14:41] <jmichel-otb> but this can be discussed
[14:42] <cresson> okay
[14:42] <gpasero> I can do the RM, or backup if needed
[14:42] <cresson> I am not very experienced with git yet
[14:43] <gpasero> don't worry, the RM doesn't merge things himself
[14:43] <inglada> but for a first run, someone with some experience would be safer, I mean that jmichel-otb, grizonnetm, gpasero or msd would be better for a first experiment if cresson wants to wait and see
[14:43] <cresson> okay
[14:43] <gpasero> he only check that the branch is healthy enough to be merged
[14:43] <jmichel-otb> agree
[14:43] <cresson> yes, I think it could be better if I observe & learn first
[14:43] <jmichel-otb> on the other hand, an external point of view would help to enforce those new guidelines
[14:43] <inglada> OK, so we vote for cresson as RM and gpasero as BRM?
[14:44] <inglada> sorry, some latency here
[14:44] <jmichel-otb> ok I can do the rm and gpasero the backup
[14:44] <cresson> or you will have to assist me
[14:44] <gpasero> sure,
[14:45] <jmichel-otb> so cresson it is up to you
[14:45] <gpasero> maybe you can take the BRM,
[14:45] <jmichel-otb> we can start like this and if you really do not feel it I can always replace you
[14:45] <grizonnetm> cresson can be BRM?
[14:46] <jmichel-otb> it must also be acknowledged that it will require a bit of time
[14:47] <jmichel-otb> ok I propose that we move on and cresson will let us know at the end of the meeting if he wants to try
[14:47] <jmichel-otb> no pressure
[14:47] <jmichel-otb> otherwise I will do it
[14:47] <grizonnetm> ok
[14:47] <cresson> I am weigthing this, given the fact it's new for me. But hey, there is always something new
[14:47] <jmichel-otb> and gpasero is brm whatsoever
[14:48] <inglada> OK, so we vote for cresson as RM and gpasero as BRM?
[14:48] <inglada> ;)
[14:48] <jmichel-otb> +1 for me
[14:48] <inglada> +1
[14:48] <grizonnetm> next subject?
[14:48] <jmichel-otb> lets get back to bugfixes
[14:48] <cresson> Ok
[14:49] <jmichel-otb> I propose that all tracked bugs are solved on a branch started from the last release
[14:49] <inglada> agreed
[14:49] <jmichel-otb> and merged in develop upon resolution
[14:49] <inglada> you mean one branch per bug, right?
[14:50] <inglada> or a bugfix branch?
[14:50] <jmichel-otb> we can have a general bugfix branch, and branch from there ;)
[14:50] <jmichel-otb> in this branch we can then tag minor releases
[14:51] <inglada> OK
[14:51] <jmichel-otb> this is for tracked issues
[14:51] <grizonnetm> in my understanding it was 1 temporary branch for each bug
[14:52] <jmichel-otb> ok
[14:52] <inglada> ok
[14:52] <jmichel-otb> but it would be good to be able to release 5.0.1 with a few bugfixes
[14:52] <jmichel-otb> so merge is actually both to develop and 5.0.0 branch no ?
[14:53] <grizonnetm> in the gitflow yes
[14:53] <inglada> we have a picture http://wiki.orfeo-toolbox.org/index.php/Git#What_model_should_be_used.3F
[14:54] <jmichel-otb> ok
[14:54] <jmichel-otb> for bugs affecting develop only (i.e. not released), I suggest they can be fixed directly in develop or in the corresponding feature branch
[14:54] <gpasero> note : the initial idea was to do bugfixes in the 5.0.0 branch to that the minor release can be tagged in this branch
[14:55] <jmichel-otb> gpasero, yes, but it does not hurt to fix in a dedicated branch and merge back to 5.0.0 branch
[14:55] <grizonnetm> result is the same
[14:56] <grizonnetm> i think that what we have on the wiki page is OK
[14:56] <jmichel-otb> rm approves those bug fixes merge too (todo: add a separate checklist for tracked bugfix merges)
[14:56] <jmichel-otb> yes
[14:56] <grizonnetm> we just need to better describe where bugfixes happened and how to merge it back to develop
[14:56] <jmichel-otb> ok
[14:57] <jmichel-otb> are we done with the git workflow ?
[14:57] <jmichel-otb> does anyone want to add something ?
[14:57] <inglada> yes
[14:57] <jmichel-otb> ok lets move on
[14:57] <jmichel-otb> next topic is RFCs process
[14:57] <inglada> no
[14:58] <inglada> hey, i have a question!
[14:58] <jmichel-otb> k
[14:58] <inglada> In my understanding, the issue is not *when* to create a branch (it should always be the case), but when to wait for approval before merging. am I right?
[14:59] <jmichel-otb> inglada: sort of, it is when to request for merge approval
[14:59] <inglada> tht's what I meant
[15:00] <jmichel-otb> ok
[15:00] <inglada> I mean that even when you work alone, you are supposed to create a new branch for everything, then you merge and eventually remove the branch
[15:00] <inglada> OK. Thanks. We can move on.
[15:01] <grizonnetm> yes and when a branch is submitted, it is tested across the three major platforms before being merged to develop
[15:01] <cresson> what are exactly the "tested" (visible on the dashboard) branches?
[15:02] <cresson> nigthly? ...
[15:02] <jmichel-otb> nightly branch is forked automatically everyday
[15:02] <jmichel-otb> from last commit before ... 8:00 PM ?
[15:02] <cresson> yes, but nightly is the same as develop, am I right?
[15:02] <rashad> grizonnetm: how is the testing of branches before merging is done? and by who?
[15:03] <grizonnetm> 19:50 PM
[15:03] <jmichel-otb> it is a given state of develop
[15:03] <msd> not exactly if you commit after 8 it is not the same content
[15:03] <jmichel-otb> grizonnetm, at least it is not 19:50 AM ;)
[15:04] <rashad> i mean on all major platforms and etc.
[15:04] <jmichel-otb> rashad: testing is done as for now : only a single plateform tests feature branches
[15:04] <cresson> so, in order to be tested and validated, a feature branch has to be merged back to develop
[15:05] <jmichel-otb> theoretically yes but we can not afford this
[15:05] <cresson> that's what inglada was asking
[15:05] <jmichel-otb> currently we have a file here : https://git.orfeo-toolbox.org/otb-devutils.git/blob/HEAD:/Config/feature_branches.txt
[15:06] <jmichel-otb> all branches recorded here will be tested on a daily basis
[15:06] <jmichel-otb> but only by one configuration
[15:06] <cresson> ok
[15:06] <jmichel-otb> see http://dash.orfeo-toolbox.org/index.php?project=OTB
[15:06] <rashad> jmichel-otb: just a question. could we merge everything from develop and feature branches to nightly and then test nightly.
[15:06] <gpasero> at the moment , MacOS and Win are not tested with these feature branches
[15:06] <inglada> I guess this is enough
[15:07] <jmichel-otb> rashad, we could but this is an even more complex workflow
[15:07] <inglada> the differences between platforms will not be big issues for feature branches
[15:07] <rashad> i mean nightly is not used other than for dashboard and is merged automatically from develop. why not include feature branches. so all platform testing is not cistly
[15:07] <jmichel-otb> inglada: I agree
[15:07] <rashad> jmichel-otb: okay
[15:08] <jmichel-otb> rashad, yes, but nothing guarantees that all branches will merge nicely in nightly
[15:08] <jmichel-otb> most likely there will be conflicts
[15:08] <inglada> nicely in nightly ...
[15:09] <gpasero> note : nightly is updated only by fast-forward, no commit generated
[15:09] <rashad> if it adds more complex to workflow. leave it that way.
[15:09] <jmichel-otb> ok
[15:09] <jmichel-otb> are we done with git workflow ?
[15:09] <grizonnetm> ye
[15:09] <cresson> huh
[15:10] <cresson> I have questions about git flow:
[15:10] <cresson> Some people can fork the otb on git, and they potentially could fix bugs
[15:10] <cresson> how can they merge back their fix?
[15:11] <inglada> they send a patch?
[15:11] <gpasero> using GitHub pull request I guess
[15:11] <cresson> their branche does not appear in the list grizonnetm mentioned
[15:11] <jmichel-otb> cresson I think we can adress this issue in the following topic (contributors guidelines)
[15:11] <cresson> ok
[15:11] <jmichel-otb> so lets talk about RFCs
[15:12] <jmichel-otb> this is linked to the git workflow since the first thing checked by RM is that a RFC correspond to the feature branch
[15:12] <jmichel-otb> what do you think of the current rfc process
[15:13] <inglada> I find it difficult to know when we are supposed to vote ...
[15:13] <jmichel-otb> agreed
[15:13] <cresson> yes
[15:13] <jmichel-otb> I find it difficult to write consistent rfc also
[15:14] <jmichel-otb> I mean, it would be easier to describe the rfc and vote for it when the work is already done ;)
[15:14] <rashad> i am not sure when to propose an rfc.
[15:15] <inglada> if you feel you need a feature branch, propose an rfc, otherwise it won't be merged ;;)
[15:16] <jmichel-otb> yes that is what we decided earlier
[15:16] <jmichel-otb> but you can do the rfc when requesting merge
[15:16] <rashad> ok
[15:17] <cresson> ok
[15:17] <inglada> I guess that it is important to submit an rfc beforehand for big features
[15:17] <jmichel-otb> I mean the purpose for me is unclear : if you submit a RFC before writing code, and then do a crappy code work it will get merged without trouble
[15:18] <inglada> code review?
[15:18] <grizonnetm> gerrit?
[15:18] <jmichel-otb> this would solve the merge request issue ;)
[15:19] <inglada> but would increase the ticket to get in
[15:19] <jmichel-otb> what if we do the following
[15:19] <grizonnetm> ticket to get in OTB > ticket to get in Gerrit
[15:20] <jmichel-otb> RFC is submitted early to start discussion and communicate the new feature project
[15:20] <jmichel-otb> but we only vote when it is done
[15:20] <grizonnetm> done ?
[15:20] <inglada> OK for me
[15:20] <jmichel-otb> done = ready to merge
[15:21] <jmichel-otb> this add one step in the merge process
[15:21] <inglada> or maybe this
[15:21] <inglada> RFC -> vote -> development -> review -> vote -> merge
[15:21] <cresson> this looks much clear for me
[15:22] <gpasero> the developer could also cast a vote when the feature (or at least a part of it) is ready for merge
[15:22] <jmichel-otb> ok so that makes 2 votes
[15:22] <jmichel-otb> and we have trouble voting once for now ;)
[15:23] <jmichel-otb> who will do the code review ?
[15:23] <inglada> for a contributor who likes risks : development -> RFC -> vote -> review -> vote -> merge
[15:23] * nhv see the flow as RFC -> discussion -> development -> review -> vote -> merge
[15:23] <gpasero> RFC -> development -> first feedbacks and comments -> review -> vote -> merge
[15:24] <inglada> code review may be done by RM and at least someone else
[15:24] <jmichel-otb> i think this is too much for rm
[15:24] <cresson> who used to code review before?
[15:24] <inglada> who is the RM ;)
[15:24] <jmichel-otb> if RM is a full time job we will not have a lot of volunteers
[15:24] <cresson> lol
[15:24] <cresson> indeed
[15:25] <inglada> OK. code review is done by 2 volunteers
[15:25] <jmichel-otb> if we go this way we definitively need gerrit
[15:25] <inglada> while there are not 2 reviews done, vote can not happen
[15:26] <jmichel-otb> ok but let aside review, I see other issues
[15:27] <jmichel-otb> we said that we need small branches
[15:27] <jmichel-otb> that need to be merged often
[15:27] <jmichel-otb> it is not really compatible with vote (for one RFC) before merge
[15:28] <grizonnetm> completely incompatible
[15:28] <jmichel-otb> I mean I can have 4 or 5 short branches corresponding to one rfc
[15:29] <gpasero> it means that RFC vote has to happen earlier
[15:29] <jmichel-otb> we could do the following: we do not vote for RFCs, only for branch merge
[15:29] <jmichel-otb> I mean the only purpose of early RFC submission is to gather PSC agreement
[15:29] <jmichel-otb> but you can gather it without a vote
[15:30] <nhv> RFC == Request for Comment
[15:30] <inglada> I think if you can do the feature on your own, you don't need rfc
[15:30] <jmichel-otb> if you open a RFC and everyone says it is a bad idea, you do not proceed to development
[15:30] <jmichel-otb> so we actually need formal votes only when merging
[15:30] <jmichel-otb> because merging is what decides what is in OTB
[15:30] <jmichel-otb> in the end
[15:31] <inglada> but RM is supposed to approve the merge?
[15:31] <jmichel-otb> nvh can you develop ?
[15:31] <nhv> I have
[15:31] <PhilippeML> jmichel-otb: «everyone says it is a bad idea» is a kind of vote… no ?
[15:32] * nhv has been comitter to mapserver, gdal, osssim, geos, postgis in past
[15:32] <jmichel-otb> nvh I meant what do you mean by saying "RFC == Request for Comment"
[15:33] <inglada> Actually, RFC is a request for changes
[15:33] <nhv> https://www.ietf.org/rfc.html
[15:34] <inglada> I know, but http://wiki.orfeo-toolbox.org/index.php/Project_Steering_Committee#When_is_a_PSC_vote_required.3F
[15:34] <nhv> oops sorry
[15:35] <inglada> No problem, we already had this conversation in the past ;)
[15:36] <inglada> since A Request for Change (RFC) describes a change in Orfeo ToolBox code, API, infrastructure or processes that need to be submitted to the PSC vote:
[15:36] <inglada>
[15:36] <inglada> * Anything that could cause backward compatibility issues,
[15:36] <inglada> * Adding substantial amounts of new code,
[15:36] <inglada> * Changing inter-subsystem APIs, or objects,
[15:36] <inglada>
[15:36] <inglada> maybe small features don't need RFC
[15:36] <jmichel-otb> lets put it this way : how can we agree to merge something in a near future on the basis of a small description with no code attached ?
[15:36] <jmichel-otb> that is why nobody votes as I see it
[15:36] <inglada> I agree, that's why RFC -> vote -> development -> review -> vote -> merge
[15:37] <jmichel-otb> so question is: can we skip the first vote ?
[15:37] <jmichel-otb> to kis
[15:37] <inglada> maybe RFComents -> vote -> development -> RFChanges -> review -> vote -> merge
[15:37] <inglada> or better RFComents -> comments -> development -> RFChanges -> review -> vote -> merge
[15:38] <nhv> +1
[15:38] <jmichel-otb> I like this
[15:38] <grizonnetm> +1
[15:38] <inglada> +1
[15:38] <cresson> ok
[15:39] <inglada> I think that the RFComents gives visibility and lowers the risk of overlap
[15:39] <jmichel-otb> yes
[15:39] <jmichel-otb> it also lower the risk for the developer
[15:39] <jmichel-otb> if he wants to port OTB in java for instance
[15:39] <inglada> who cares? ;)
[15:39] <grizonnetm> to we need a RFC to agree about the RFC workflow :) ?
[15:39] <cresson> excellent jmichel-otb
[15:40] <nhv> you need group discussion before committing to lots of work
[15:40] <jmichel-otb> grizonnetm: the purpose of this meeting is to take decision rapidly
[15:40] <jmichel-otb> so I would say no
[15:40] <inglada> what is exactly the questio?
[15:41] <inglada> RFC for got workflow?
[15:41] <inglada> I think not
[15:41] <jmichel-otb> no RFC for RFC workflow
[15:41] <jmichel-otb> whatever
[15:41] <inglada> for(;;);
[15:41] <grizonnetm> ok ok
[15:42] <inglada> next topic?
[15:42] <jmichel-otb> release manager still holds in this new RFC^2 workflow : he can approve merge once RFChange is approved (and other items of the checklist are done)
[15:42] <cresson> ok
[15:42] <inglada> ok
[15:42] <jmichel-otb> ok so I will try to better describe this and rework the RFC template
[15:42] <jmichel-otb> And I will get back to the list with a proposal
[15:43] <jmichel-otb> This also implies that you can directly come with a RFChange
[15:43] <grizonnetm> good
[15:43] <jmichel-otb> if it is small or you already did it for some other project
[15:43] <jmichel-otb> and it can be merged quickly if it gets voted
[15:44] <jmichel-otb> ok next topic is "what to do with roadmaps" gathered by Jordi
[15:44] <inglada> Trashcan
[15:44] <inglada> http://wiki.orfeo-toolbox.org/upload/4/45/Roadmaps.png
[15:45] <inglada> The purpose of roadmaps was to give visibility of the direction OTB is going
[15:45] <jmichel-otb> yes
[15:46] <inglada> But since RFCs can come at any time, it is difficult to build consistent roadmaps
[15:46] <jmichel-otb> as I see it, your chart is more a map of all possible roads we could go ;)
[15:46] <inglada> yes
[15:46] <inglada> a roadmap not a single path from a to b
[15:46] <gpasero> a real roadmap would rather be : what will be in 5.4, 5.6, in 6.0 ...
[15:47] <inglada> but we can not know before hand unless PSC gives directions
[15:47] <jmichel-otb> and for a start we do not really have "what will be in 5.2"
[15:47] <gpasero> the PSC can agree on "high level" goals or features
[15:47] <jmichel-otb> I understand your point jordi
[15:48] <inglada> and PSC can give directions, but if there is no resources, we will not make progress
[15:48] <jmichel-otb> since PSC has no development team or mean it can not really say "this is what we will do in the next years"
[15:48] <inglada> right
[15:49] <jmichel-otb> but there are some people (psc or not) that are responsible for team or project that will contribute to OTB
[15:49] <jmichel-otb> so maybe the roadmap should be what they plan to do
[15:49] <inglada> and we are not going to vote "no" to an RFC because it is not in the roadmap
[15:50] <jmichel-otb> or even better : all possible ways (your graph) and what is currently planned by who
[15:50] <inglada> my idea at the beginning was
[15:50] <jmichel-otb> thing is that it removes the steering power from the PSC a bit
[15:51] <inglada> map everything and tag what people propose to do
[15:51] <jmichel-otb> and when
[15:51] <jmichel-otb> that is still a good idea no ?
[15:52] <inglada> well, I would like to have some feedback about what has been collected
[15:53] <jmichel-otb> ok so maybe we can do that
[15:53] <jmichel-otb> can everyone agree to spend some time on this roadmap chart and send some feedback on otb-delelopers ?
[15:53] <grizonnetm> ok
[15:53] <gpasero> sure
[15:54] <jmichel-otb> are all nodes developped inglada  ? I see a classification node
[15:54] <grizonnetm> what is the meaning of Intro?
[15:55] <inglada> I will make the org file available. This is just an export to Freemind
[15:55] <jmichel-otb> ok good
[15:55] <grizonnetm> ok
[15:55] <jmichel-otb> shall we move on ?
[15:55] <inglada> OK
[15:55] <jmichel-otb> ok contributors guidelines
[15:56] <jmichel-otb> there is a lot already with the rfc^2 and git workflow
[15:56] <jmichel-otb> we only need to clarify what should be done when author does not have push rights to OTB git
[15:56] <grizonnetm> just to finish with roadmap
[15:56] <cresson>
[15:57] <jmichel-otb> btw, we should collect a public list of people with such rights
[15:57] <jmichel-otb> and add a process to get those rights
[15:57] <grizonnetm> sorry forget it
[15:58] <jmichel-otb> so I wrote the following http://wiki.orfeo-toolbox.org/index.php/Contributors_guidelines#Contributing_code_to_OTB_sources
[15:58] <jmichel-otb> see the bottom of the page
[15:58] <jmichel-otb> it needs to be changed a litle according to what we decided
[15:59] <jmichel-otb> but maybe it is enough
[16:00] <gpasero> seems fine for me
[16:00] <inglada> the only missing piece is the "OTB coding style"
[16:00] <gpasero> only missing the rule to grant write access
[16:01] <jmichel-otb> ok
[16:02] <jmichel-otb> coding style is something we are long missing
[16:02] <jmichel-otb> anything else ?
[16:02] <jmichel-otb> Is there a volunteer to update this ?
[16:02] <gpasero> I can do it
[16:02] <jmichel-otb> ok
[16:03] <jmichel-otb> anything else ?
[16:03] <jmichel-otb> next topic : monteverdi2
[16:03] <grizonnetm> next topic
[16:03] <jmichel-otb> following the hackfest, we did what was discussed
[16:04] <jmichel-otb> we have a new software (brilliantly called mv2) that is Ice in QT with the graphical components from Monteverdi2
[16:04] <jmichel-otb> two issues here :
[16:05] <jmichel-otb> 1) we need to get those development managed by psc processes as well
[16:05] <jmichel-otb> 2) how do we tell adopters of Monteverdi2 that we changed everything (again) ?
[16:05] <grizonnetm> more than a development manage by a PSC, we need to have a dev process more open for monteverdi2
[16:06] <jmichel-otb> yes this is what I meant
[16:06] <jmichel-otb> but it is not easy to ben open all the sudden
[16:07] <jmichel-otb> so I think a good thing would be to release this new version and starts from there
[16:07] <jmichel-otb> RFC^2, release manager and everything
[16:09] <grizonnetm> agree to start with RFCs and everything after the release of mv2
[16:09] <jmichel-otb> which bring us to point 2
[16:09] <jmichel-otb> \alert others to you have comments ?
[16:10] <grizonnetm> for 2), don't have a great idea
[16:10] <jmichel-otb> I do not need irc to discuss with grizonnetm, he sits right in front of me ;)
[16:10] <inglada> you say everything changed
[16:10] <cresson> I would ask if RM is concerned about mv2 too?
[16:11] <grizonnetm> other than saying to people that w've changed everything (politely)
[16:11] <inglada> I thought the full application would still exist
[16:11] <jmichel-otb> cresson, ideally yes
[16:11] <jmichel-otb> we need to figure out if it is the same RM
[16:11] <jmichel-otb> inglada, for now, everything exists
[16:12] <jmichel-otb> but as a viewer, mv2 is far better than monteverdi2
[16:12] <inglada> I thought there was the viewer (mv2), the launcher (mapla) and the full application
[16:12] <jmichel-otb> yes you are right
[16:12] <jmichel-otb> these 3 components still exist
[16:13] <inglada> so these are no real "changes", just new ways of using monteverdi2
[16:13] <gpasero> It would be better to present mv2 as a new tools, and do a lot of communication on it
[16:13] <jmichel-otb> inglada: that is one option of communication
[16:13] <jmichel-otb> but in the long term it will be heavy for us to maintain those 3 components
[16:14] <jmichel-otb> and mv2+mapla is far better to use than monteverdi2
[16:14] <jmichel-otb> if we get mapla in mv2 (which looks rather easy), I see no point of having monteverdi2 around
[16:14] <inglada> let the users come to that conclusion
[16:14] <grizonnetm> tbc
[16:15] <jmichel-otb> in fact the part that is different from monteverdi2 is all those things about persistency and dataset management
[16:15] <jmichel-otb> it does not exist in mv2
[16:16] <grizonnetm> and image stacking
[16:16] <jmichel-otb> yes
[16:16] <grizonnetm> which does not exist in monteverdi2
[16:16] <jmichel-otb> we could do a table to show differences
[16:16] <jmichel-otb> on one hand mv2 is fast and allows to display multiple images at a time
[16:17] <jmichel-otb> on the other monteverdi2 remembers the data that where loaded and the rendering setup, and allows for application processing
[16:18] <jmichel-otb> The way I see things, the application I dreamed of is mv2 and it is a solid basis to grow new features
[16:19] <jmichel-otb> monteverdi2 was a draft with all sorts of mistakes
[16:19] <gpasero> let's communicate that mv2 is far better
[16:20] <grizonnetm> mv2 is amazing
[16:20] <gpasero> and also help users to migrate from MVD2 to mv2
[16:20] <jmichel-otb> it also cures heavy deseases and makes your whole life better
[16:21] <inglada> we need mapla into mv2 before talking about deprecating monteverdi2
[16:21] <jmichel-otb> I agree
[16:21] <PhilippeML> Silly question: what mv2 stands fo ?
[16:21] <PhilippeML> what mv2 means ?
[16:21] <jmichel-otb> if we want to propose mv2 instead of monteverdi2 they need to be equivalent in terms of functions
[16:22] <jmichel-otb> and we need to find a real name
[16:22] <inglada> yes
[16:22] <inglada> monteverdi3
[16:22] <inglada> or event monteverdi <3
[16:22] <inglada> or even "I <3 Monteverdi"
[16:22] <jmichel-otb> I think I may work: the look and feel is the same, some components are different, but all in all it can be presented as an evolution
[16:23] <jmichel-otb> mv^2 is MonteVerdi Viewer
[16:23] <jmichel-otb> crappy name
[16:23] <grizonnetm> +1
[16:23] <PhilippeML> and what about «otb-viewer» so ?
[16:23] <rashad> a name similar to ice would be nice. as the core part is ice.
[16:24] <jmichel-otb> rashad, this would be good if ice was not a crappy name too ;)
[16:24] <inglada> Freeze
[16:24] <grizonnetm> if we put mapla inside mv2 and present it as an evolution monteverdi3 is not a bad idea
[16:24] <jmichel-otb> I agree
[16:25] <jmichel-otb> Ok so lets do this : mapla inside mv2, name it monteverdi2
[16:25] <gpasero> PhillipeML : otb-viewer already existed :)
[16:25] <jmichel-otb> monteverdi3 sorry
[16:25] <jmichel-otb> it is good to keep with the brand
[16:25] <inglada> ok for monteverdi 3
[16:25] <inglada> and let's make t-shirts
[16:25] <inglada> and mugs
[16:25] <grizonnetm> a a sense that it could allow for users to detect a kind of coherence in this process
[16:25] <jmichel-otb> during hackfest we decided to make a beta version
[16:26] <jmichel-otb> it is ready (almost) but it lacks the mapla
[16:26] <jmichel-otb> do we wait ?
[16:26] <grizonnetm> wait for what?
[16:26] <jmichel-otb> for mapla to be available inside monteverdi3 ?
[16:27] <inglada> the beta version could be mv2 and mapla side by side, then merge them for monteverdi3
[16:27] <jmichel-otb> ok sounds good for me
[16:27] <grizonnetm> k
[16:28] <jmichel-otb> and right after the beta version we get monteverdi3 in psc scope
[16:28] <inglada> which means?
[16:28] <jmichel-otb> rfc, rfc, merge request, release manager
[16:28] <inglada> ok
[16:28] <grizonnetm> roadmaps
[16:28] <jmichel-otb> and everything happens on otb-developers
[16:28] <jmichel-otb> which is not the case for now
[16:29] <jmichel-otb> I think that we could do this beta version really soon
[16:29] <jmichel-otb> I mean I saw some feedback on otb-developer
[16:29] <jmichel-otb> today
[16:29] <jmichel-otb> but we do not need to wait for feedbacks before the beta, since it is the purpose of the beta to get feedback
[16:30] <inglada> so we disconnect OTB and monteverdi releases?
[16:30] <jmichel-otb> that is a tough one
[16:30] <jmichel-otb> for me a beta release of mv2+mapla is a matter of binary packages
[16:31] <jmichel-otb> and a tag
[16:31] <jmichel-otb> it can be done with develop
[16:31] <jmichel-otb> but we can do a formal release if psc thinks it is better
[16:31] <jmichel-otb> in which case the question holds
[16:31] <inglada> I would agree for mv2, but not for mapla
[16:31] <inglada> I mean, using develop
[16:32] <inglada> mapla uses the applications
[16:32] <jmichel-otb> if develop == ship it ...
[16:32] <jmichel-otb> lets ship it !
[16:32] <inglada> but the applications in mapla may be different from those on the closest OTB release
[16:33] <grizonnetm> if we disconnect otb and monteverdi releases
[16:33] <grizonnetm> we need to test this configuration
[16:34] <grizonnetm> IMO for now monteverdi2/mv2/mapla are using the develop branch of OTB
[16:34] <grizonnetm> and the situation is the same with ice
[16:34] <jmichel-otb> that is why I proposed to have everything as module in OTB ;)
[16:35] <inglada> it's not just a matter of test, but also a matter of being able to use the same versions of the applications in mvd and the library
[16:35] <inglada> if we disconnect releases, we may still use the latest stable OTB for releasing monteverdi
[16:36] <inglada> instead of develop
[16:36] <jmichel-otb> thing is it is quite a constaint to develop monteverdi2/3 wihtout touching anything in OTB
[16:36] <gpasero> I find this option better
[16:36] <inglada> so keep releases in syc
[16:36] <jmichel-otb> in many situations we need develop
[16:36] <inglada> sync
[16:36] <jmichel-otb> ok maybe the best option
[16:37] <jmichel-otb> anyway, for a beta intended to get feedbacks, we can do with develop
[16:37] <jmichel-otb> no ?
[16:37] <inglada> OK for the beta
[16:37] <grizonnetm> yes
[16:38] <jmichel-otb> last topic was introduced by rashad i think
[16:38] <jmichel-otb> Discuss about single code license for sources under ossimplugins (LGPL-2 / LGPL-3 / Apache(upcoming OTB) / MIT (ossim) )
[16:38] <jmichel-otb> this is a topic for the legal issues role ;)
[16:39] <grizonnetm> bip bip bip
[16:39] <rashad> the question was raised by debian package review
[16:39] <inglada> are apache and mit compatible?
[16:39] <inglada> who is in charge for ossimplugins?
[16:40] <grizonnetm> which question?
[16:40] <rashad> some or all of the code in thirdparty/ossimplugins can be merged to ossim core rather than a seperate plugins.
[16:41] <jmichel-otb> ok
[16:41] <jmichel-otb> but ?
[16:41] <inglada> so we should use mit to make things easier for ossim
[16:41] <rashad> some explicitly says LGPL-3
[16:41] <inglada> who wrote that code?
[16:42] <nhv> fwiw the top level license @ https://trac.osgeo.org/ossim/browser/trunk/ossim_plugins/LICENSE.txt is LGPL v2.1
[16:42] <rashad> which code LGPL-3?
[16:42] <rashad> nhv, ossim core has now MIT license
[16:43] <nhv> the top level ossim core https://trac.osgeo.org/ossim/browser/trunk/ossim/LICENSE.txt is MIT
[16:44] <rashad> we use the ITK license with any itk related code as upstream changes their's among different version.
[16:44] <nhv> sounds like a good policy
[16:44] <rashad> so this can be applied to ossim also. but it has to be decided by others.
[16:45] <nhv> right
[16:46] <jmichel-otb> inglada, SAR sensors are copyright cnes I think
[16:46] <rashad> all sensor models are copyright cnes.
[16:46] <grizonnetm> example: https://trac.osgeo.org/ossim/browser/trunk/ossim_plugins/ossim/ossimAlosPalsarModel.h
[16:48] <inglada> Sorry guys, I have to go
[16:48] <jmichel-otb> yes this meeting was too long
[16:48] <grizonnetm> difficult for me to follow the discussion
[16:48] <jmichel-otb> we can see this issue in otb-developers rashad
[16:48] <rashad> okay.
[16:49] <jmichel-otb> sorry guys thanks for participating
[16:49] <nhv> looks like all files in ossim_plugins/ossim are LGPL <see license at top level directory >
[16:49] <jmichel-otb> I will post logs on wiki and try to sum up the conclusiosn
[16:49] <grizonnetm> could be nice to extract "TODOs" from the log
[16:49] <grizonnetm> thanks all
[16:50] <nhv> fwiw I have been monitoring looks to me as if you folks should be well on the way to incubation
[16:50] <nhv> 'are well on the way ...'
[16:50] <jmichel-otb> yes we need to complete the code provenance review
[16:51] <jmichel-otb> which we need to do anyway because we are planning to change licence to apache 2.0
[16:51] <jmichel-otb> and we will be done
[16:51] <nhv> gottcha  :-)