Skip to end of metadata
Go to start of metadata
paulsherwood== GENIVI Tools Team Meeting Starts ==14:00
paulsherwoodklausbirken: welcome back :)14:00
paulsherwoodgmacario: hi14:00
philrobhi !14:00
*** pavelk has joined #automotive14:00
*** tcouniha has quit IRC14:00
paulsherwoodphilrob: :-)14:00
klausbirkenpaulsherwood: thanx14:00
paulsherwoodso i propose the normal agenda, but first...14:01
paulsherwoodi notice that exists14:01
* jeremiah waits . . .14:01
paulsherwoodsadly i can't actually log into it!14:01
jeremiahNor can I14:01
paulsherwoodbut i'm guessing that future content needs to go there14:01
jeremiahI've sent an email to GENIVI IT about it14:01
gunnarxI'm just now trying a password reset, account seems to be there14:02
* paulsherwood has tried reset.... no sign14:02
paulsherwooddoes anyone have proposed agenda items?14:02
gmacarioRe: vs https://genivi-oss.atlassian.net14:03
* paulsherwood thinks 'Note: This cloud-based version of GENIVI's Open Source projects is now historical. The current version is the server version of Confluence located here: User credentials have been maintained (and are the same).' is not actually true14:03
* gunnarx also failed logging in14:03
paulsherwoodagenda items for this meetign in general, gmacario14:03
gmacarioI just realized that gunnarx has commented in but there is also a new
* paulsherwood has one but it can wait til aob14:03
philrobcredentials for will be at the agena of pmo call tomorrow (I have also problems and sent already an email to genivi IT)14:03
gunnarxyes, I know14:03
paulsherwoodphilrob: ok thanks14:04
gunnarxit was the only one I could log in to :-D14:04
paulsherwoodso for the moment... last week's content is at
paulsherwoodmoving on...14:04
paulsherwood- Build Tools -14:04
jeremiahI think we want to add the AAP code to GDP14:05
jeremiahDoes that qualify for a "build tools" topic?14:05
gunnarxtypical build tool issue :)14:05
paulsherwoodjeremiah: i believe GDP is normally to be discussed in BIT14:05
paulsherwoodbut my AOB item involves this14:05
jeremiahOkay, then I'll send an email to genivi-projects and cc the BIT14:05
paulsherwoodjeremiah: good idea14:06
philrobyeap, I will discuss it with Korea to-morrow morning, it is not a topic for build tools IMO14:06
gunnarxyes, but maintainers are also in #automotive, so you're not that far off14:06
jeremiahTo be honest, I was hoping for a little info leakage. :-)14:06
gunnarxanyway, Paul what is a build tool again?14:06
paulsherwoodklausbirken: i have an outstanding action to discuss franca/franca_install_automation with you14:06
philrobI have sent already an note to GDP maintainers on it, my objective is that they bring the AAP code maintainer into genivi-projects14:07
gunnarxI always get confused too about what goes where in the agenda, tbh14:07
paulsherwoodgunnarx: i think i explained my perspective on tools in general :)14:07
klausbirkenpaulsherwood: ok14:07
paulsherwoodklausbirken: basically i think the question is, could franca_install_automation become officially part of franca?14:07
* paulsherwood may be wrong14:08
klausbirkenpaulsherwood: could be… have to think about it14:08
paulsherwoodklausbirken: great... can i assign the action to you now? :-)14:09
jeremiahklausbirken: If it does belong upstream, perhaps we can note that here:
jeremiahJust for clarity.14:09
gunnarxOK, I can see from last week's minutes that franca_install_automation is part of build tools topic, good.14:09
gunnarxif I may provide some input, as the creator of the project :)14:09
paulsherwoodgunnarx: please go ahead14:09
gunnarxAfter spending probably 8 hours trying to get IONAS in there I think my approach doesn't really scale that well...14:09
klausbirkengunnarx: what would you think about merging install_automation into franca?14:10
gunnarxIt's a LOT of effort to install all dependencies manually.  Either I need to tap into what eclipse already does, or going back to some manual install step is maybe the only reasonable way14:10
klausbirkenyes, this is lot of effort...14:11
gunnarxTo explain to those who don't get it, _every_ dependency recursively is _explicitly_ installed in my script.  Normal eclipse - you just point to the sites and select the topmost package and it figures out all dependencies that are needed.14:11
klausbirkenin general, I think install_automation wants to bundle Franca and tools using Franca (i.e., CommonAPI, IoNAS)14:11
klausbirkenso it might not be the best idea to put everything into one project14:12
gunnarxthe whole eclipse ecosystem is dependency hell, my perception.  would like to chat more with klausbirken how he even manages to develop stuff that works :-)14:12
paulsherwoodgunnarx: so are you thinking that install_automation has no future, or?14:12
gunnarxpaulsherwood:  it's useful in its current state, but I'm uncertain if it really is the right approach14:12
gunnarxobviously incremental updates are easier once a certain feature is in there.14:13
gmacarioWell IMHO requirements behind franca_install_automation are quite OK14:13
gmacario"make Franca installation easy" :-)14:13
gmacarioand CommonAPI-C++14:13
paulsherwoodgunnarx: understood. but if it's useful, incorporating it into franca upstream seems worthwhile?14:13
gmacarioand IoNAS, etc14:13
gunnarxsure, I suspect eclipse people would like to do it differently though14:14
paulsherwoodanyways, i think an action is on klausbirken to consider14:14
gunnarxbut starting the conversation with those in the know should help, I might be doing things wrong...14:14
gunnarxyes, would be nice if klaus can help14:14
klausbirkenregarding the dependency problem when building an Eclipse instance, the Oomph project might be useful (
*** waltminer has joined #automotive14:15
klausbirkenit has a slightly different scope, but maybe we could use it anyway14:15
paulsherwood+1 for looking at existing solutions14:15
gunnarxI have limited bandwidth learning about all eclipse details I feel since i just want the GENIVI tools to work, but ...14:15
*** tcouniha has joined #automotive14:15
paulsherwoodgunnarx: we need other volunteers? :)14:16
paulsherwoodany other franca users here?14:16
gunnarxYes. Oomph is apparently an Eclipse way to automate installs.14:16
paulsherwoodshall we move on?14:17
klausbirkengunnarx: I don't know yet if Oomph and vagrant can be combined nicely...14:17
gunnarxI think so.  Can't commit to succeeding with IONAS at the moment.  Franca and CommonAPI tooling is usable as it is today though.14:17
klausbirkenI will try to apply Oomph for our task at hand...14:17
gunnarxOK, thanks klaus.  Let's keep in touch.14:18
fredcadeteFYI, here we use Franca and CommonAPI avoiding Eclipse most of the time14:18
paulsherwoodklausbirken: thanks! :)14:18
fredcadetewith the command-line generators14:18
paulsherwoodfredcadete: :)14:18
gunnarxWe agree to put "launching" of this tool on the back burner a while longer?14:18
paulsherwoodgunnarx: seems so14:18
klausbirkengunnarx: ok14:18
paulsherwoodany more discussion wrt Build Tools?14:18
gunnarxfredcadete:  yes, command-line and lots of other tools would likely be feasible also in my approach. That's the plan we had to turn this into an SDK builder.14:19
jeremiahPelagicore may be able to put some resources behind the command line tools14:19
gunnarxok, let's see how things go until next week.  I put so much work into the IONAS support already I likely want to try to finish anyway.14:20
paulsherwoodok. gunnarx i notice you mentioned last time a possible discussion with manfred... did that happen?14:20
paulsherwoodshall we move on?14:21
paulsherwood(should there be an action for that conversation?)14:21
gunnarxidk, I think I asked a simple question last time, didn't get a response really14:22
gunnarxthe simple question is: does franca_install_automation overlap the features of yamaica at all, or should yamaica be included in f-i-a14:22
gunnarxI thought Manfred would be in a position to clarify14:22
*** tcouniha has quit IRC14:22
gunnarxlet's move on...14:23
*** tcouniha1 has joined #automotive14:23
paulsherwood- UML Modeling -14:23
paulsherwoodthis has been silent recently... are there interested parties to discuss here?14:23
paulsherwood5,4,3,2,1 ....14:24
jeremiahManfred submitted something about it, I have to clarify14:24
jeremiahwith him14:24
paulsherwoodok, shall we leave that with you, jeremiah ?14:25
paulsherwoodany more on UML?14:25
paulsherwood- Debugging and Analysis -14:26
paulsherwoodwe previously expressed interest in having debug tools in GDP14:26
* paulsherwood wonders if there's been any thought on that elsewhere14:27
gunnarxAnd interest in pull requests that add GDB-related Eclipse packages to you know what.  :-)14:27
paulsherwoodjonathanmaw: has this been raised with the GDP team, do you know?14:27
*** phongtran has joined #automotive14:27
jonathanmawpaulsherwood: It's been mentioned before, but I don't think we've written it down as a thing to do.14:28
paulsherwoodjonathanmaw: where would such an action be raised? bugzilla?14:29
jonathanmawpaulsherwood: yes, bugzilla preferred14:29
paulsherwoodany tools team member volutneer to raise this there?14:29
gunnarxjonathanmaw, it could be about whether GDP maintainers use those tools, which ones, and how.  Probably you do on your own machines but don't think much of it.14:30
paulsherwoodpreferably someone who knows what kind of thing would be interesting14:30
gunnarxpaulsherwood:  ^^ is the above the issue to raise, or which issue?14:30
paulsherwoodi thought the issue was to include some useful debug tools into the GDP (so that users of GDP could benefit from debug capabilities)14:31
* paulsherwood could be wrong of course14:31
* paulsherwood wonders what AGL does for debug14:31
gunnarxyeah sure, I'm just pointing out the difference between host and target... GDP is target software, so we should then identify what goes on there I suppose.14:31
*** philrob has quit IRC14:32
gunnarxDLT daemon is of course obvious. It's used by some (most) standard GENIVI components14:32
paulsherwoodjonathanmaw: would you mind writing something up on this? it's not urgent, but would be a worthwhile task if/when other load on GDP is low14:32
* paulsherwood proposes to move on, unless there are other debug/analysis topics14:33
paulsherwood- Automated Testing -14:34
paulsherwoodjeremiah: any update from you on this, i believe you have been discussing elsewhere previously14:35
jeremiahI have no new update.14:35
jeremiahI think we need to discuss however.14:35
*** philrob has joined #automotive14:35
paulsherwoodplease go ahead?14:35
jeremiahFor example, there was talk in using Jenkins w/ AGL14:35
jeremiahBut I don't think that is viable at the moment because14:36
jeremiahthey mostly test the kernel14:36
gunnarxI took a quick look at JTA.  As far as I can see the actual test definitions and deployment  might be independent of Jenkins.  I'm obviously interested in at least sharing that part in a Go environment.14:36
jeremiahand there is little overlap (currently)14:36
jeremiahgunnarx: Sounds logical14:36
gunnarxSo if the scripting part of JTA is useful then it should be reused.14:36
jeremiahIn which case, perhaps we want to put the tests in Go.CD?14:36
gunnarxI ran out of steam however.  I look at too many things14:36
jeremiahThat makes two of us I'm afraid14:37
paulsherwoodgunnarx: as i understand it the approach can be used to drive pretty much any test framework?14:37
gunnarxSo I'd like to understand if the non-Jenkins part of JTA is better than LAVA (they claim it is but independent comparison would help)14:37
gunnarxoh sure, you can drive anything14:37
jeremiahLAVA is good because it is testing on the actual hardware.14:37
paulsherwoodJTA doesn't test on hardware?14:38
gunnarxthe only question is if JTA can be separated into two parts.  Initial looks like it might but would need more detailed look.14:38
jeremiahJTA does, but lacks certain LAVA peices14:38
paulsherwoodcan someone provide a link to JTA please?14:38
gunnarxI'm not entirely sure why the authors felt it was a good idea to join these very different parts into one project, but I guess it's a fast way to get something up14:38
paulsherwoodgmacario: tvm14:39
jeremiahWell, one reason was that it is already part of the Linux CE group as well as the LTSI testing suite.14:39
gunnarxwhat was?14:39
jeremiahThe thought was that it wouldn't be too hard to add automotive tests.14:39
jeremiah(The plan for JTA to add automotive.)14:39
paulsherwoodadding automotive tests seems to be harder than people think :)14:40
gmacario"the crazy automotive guys" :-)14:40
*** waltminer has quit IRC14:40
paulsherwoodso, do we have a specific action on this? somehow to compare JTA and Lava? or do we expect to need both? or somerhing else?14:40
paulsherwoodgmacario: yup14:41
gunnarxjeremiah:  I am reading that LTSI project uses JTA.  My question is rather why "Jenkins" and "Test Framework" were joined into JTA?  The  framework defining and running the tests look like it can be independent of Jenkins.  It's written in a completely different environment and language and so on.14:41
gunnarxIt's in bash btw14:42
jeremiahbash FTW!14:42
gunnarxWell written bash, but none the less :)14:42
paulsherwoodmoving on, is the spinup part of this automated testing topic?14:42
paulsherwoodany news on this gunnarx ?14:42
gunnarxI should say, it's probably portable bourne shell script.  anyway I digress14:42
jeremiahIf its portable, what's stopping us from migrating interesting bits to the Go.CD instance?14:43
jeremiahIn which case, all we need is a template or an example14:43
jeremiahAnd we're off an running14:43
paulsherwoodwell volunteered, jeremiah :)14:43
gunnarxjeremiah:  Someone needs to confirm how easy it is to split them, I wrote it above. And do the work.14:43
gunnarxbut yes, it feels like a useful thing to do14:43
paulsherwoodshall i create an action for this?14:43
jeremiahI volunteer to write / copy paste a test example14:44
jeremiahfor evaluation here14:44
jeremiahThen I hand over to others.14:44
gunnarxworthwhile to talk to JTA upstream before it becomes a fork14:44
paulsherwoodi think the aim would be to actually trigger it in the pipeline?14:44
jeremiahStarting to become to big for just little ole me14:44
gunnarxOK, so is in a bit of a holding pattern.  I'm trying to close phase 1 but have 1/3 expected agents running so far14:45
paulsherwoodgunnarx: is that the arm one?14:46
gunnarxalso, the server itself needs migration.  The temporary server will be taken offline and move to a new IP any day, and the needs to come up.14:46
gunnarxpaulsherwood:  yes, it's the arm one.14:46
paulsherwoodack. are you still seeking contribs? what's happening with the other 2?14:47
jeremiahI'm one of two, too few cycles ATM14:47
*** apinheiro has quit IRC14:47
* paulsherwood wonders if the third is here?14:47
paulsherwoodjeremiah: better to be busy, than bored :)14:48
jeremiahAsk not for whom the bell tolss . . .14:48
jeremiahtolls even14:48
gunnarxso because of the IP move and stuff I think full roll-out to users should be delayed until we know.  So I'd say don't hold your breath this week.  Soon...14:48
paulsherwoodgunnarx: ok14:48
paulsherwoodany more on Test Automation?14:48
paulsherwood- AOB -14:49
paulsherwoodany aob from you folks?14:49
gmacarioNo AoB for me14:49
gunnarxcan't think of any14:49
klausbirkenNone for me14:49
* paulsherwood has... possible move of TT meetings to early wednesday mornings?14:49
klausbirkenHow early?14:50
jeremiahI would be able tow make it fwiw14:50
paulsherwoodthis is suggested in light of overlap with BIT, and possibility of combining discussions14:50
gunnarxstarting 9.30 CET?14:50
paulsherwoodsuggestion would be (say) 10:00 CET14:50
paulsherwoodor earlier14:50
gmacario10:00 CET may work for me14:50
philrobbecause of UK time ?14:50
paulsherwoodit can be earlier, 08:30 uk time is not really *early* :)14:51
jeremiahIts 07:30 CET14:51
jeremiahThat's plenty early14:51
gunnarxsuggestion thrown around has been to do BIT first, so are we talking the starting time of BIT, or the TT that follows14:52
gunnarxoh good, one of the two14:52
jeremiahah, good to know, makes sense to have them one after the other.14:52
paulsherwoodstarting time of bit14:52
paulsherwoodor overlap them...14:52
klausbirkenwhen will TT start then?14:52
jeremiahor squish them into one?14:52
philrobI would recommend no change until we have discussed more comprehensively the genivi BIT/TT activities, might need another week14:52
paulsherwoodphilrob: noted. i was mainly asking here how folks feel about the concept14:53
gunnarxI agree, this is really just about testing the time.14:53
paulsherwoodany participants strongly opposed?14:53
gunnarxpaulsherwood:  no you asked about the time, not the concept really14:53
paulsherwoodthe concept of moving the time :)14:53
philrobyeap, no problem with a poll on coordination time14:53
paulsherwoodas a side benefit, it might make it easier for particpants in asia to join14:54
paulsherwoodwhich was raised as an objective at the AMM14:54
paulsherwooddo i take it no-one here would be strongly opposed to this?14:55
philrobhave to go now14:55
gunnarxto what!14:55
gmacarioTo change the time for TT to Wed at 10:00 CET OK for me14:55
klausbirkenI am not available for most of the Wednesdays remaining in 2015, but in 2016 it will be ok.14:55
jeremiahI heard recently that there was an Open Source conference hosted by Samsung in Korea right after our AMM that had 12,000 participants.14:55
klausbirken10 CET ok for me, too14:55
gunnarxto change the time to some time wednesday morning, no I'm not opposed.14:55
paulsherwoodto that, gunnarx :)14:55
paulsherwoodao aob?14:56
jeremiahIf you want to submit a paper to OSCON14:56
jeremiahDo it today14:56
jeremiahCfP ends tomorrow14:56
paulsherwoodany more?14:56
jeremiahAlso, 12,000 participants!14:56
gunnarxDamn, that's early...14:56
jeremiahat an open source conf!14:56
paulsherwoodjeremiah: link to that conf?14:56
jeremiahhave to dig one up14:56
* paulsherwood proposes to terminate this meeting14:57
paulsherwood== GENIVI Tools Team Meeting Ends ==
  • No labels