18:00:49 <anteaya> #startmeeting third-party 18:00:50 <openstack> Meeting started Mon Jun 16 18:00:49 2014 UTC and is due to finish in 60 minutes. The chair is anteaya. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:54 <openstack> The meeting name has been set to 'third_party' 18:00:58 <trinaths> hi all 18:01:05 <anteaya> who is here for the third-party meeting? 18:01:10 <lyxus> I am 18:01:13 <krtaylor> o/ 18:01:15 <trinaths> I am 18:01:18 <luqas> o/ 18:01:24 <sweston> o/ 18:01:25 <ilyashakhat__> o/ 18:01:35 <anteaya> great welcome 18:01:39 <anteaya> here is our agenda 18:01:43 <anteaya> #link https://wiki.openstack.org/wiki/Meetings/ThirdParty#Agenda_for_next_meeting 18:01:58 <anteaya> #topic Welcome & Reminder of OpenStack Mission 18:02:04 <anteaya> so Welcome 18:02:11 <anteaya> anyone here for the first time? 18:02:15 <SergeyLukjanov> o/ 18:02:26 <anteaya> hi SergeyLukjanov 18:02:27 <SergeyLukjanov> (not for the first time) 18:02:31 <anteaya> yeah :D 18:02:43 <anteaya> so reminding everyone what the openstack mission is 18:02:47 <anteaya> #info The OpenStack Open Source Cloud Mission: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable. 18:02:48 <lyxus> I joined the infra when we talked about CI. Not this one though 18:02:56 <anteaya> lyxus: welcome 18:03:10 <anteaya> #topic Review of previous week's open action items 18:03:25 <anteaya> there are no open action items from last week 18:03:29 <anteaya> that was quick 18:03:41 <anteaya> #topic Announcements 18:03:48 <anteaya> anyone have any announcements? 18:03:58 <anteaya> mestery: you will see I moved your item 18:04:14 <mestery> anteaya: thx 18:04:19 <anteaya> no announcements? 18:04:23 <anteaya> let's move on 18:04:27 <anteaya> #topic OpenStack Program items 18:04:43 <anteaya> #info Review of Neutron 3rd party driver/plugin requirements wiki page (mestery): 18:04:47 <anteaya> mestery: the floor is yours 18:04:53 <mestery> anteaya: Thanks 18:05:00 <mestery> #link 18:05:03 <mestery> #link https://wiki.openstack.org/wiki/NeutronPlugins 18:05:22 <mestery> So, this somewhat ties into this page as well: 18:05:30 <mestery> #link https://wiki.openstack.org/wiki/NeutronThirdPartyTesting 18:05:40 <mestery> Mostly, I had hoped to solicit feedback from everyone at this meeting. 18:05:54 <mestery> anteaya has worked with me on parts of this already, and her help was much appreciated! 18:05:59 <anteaya> np 18:06:03 <mestery> Does anyone have comments? 18:06:10 <anteaya> so all of it or any part in particular? 18:06:30 <mestery> anteaya: Well, perhaps the general direction, but specifics are fine as well. ;) 18:06:32 <anteaya> if folks are seeing this for the first time it might be a bit of a chunk to give feedback right now 18:06:41 <anteaya> okay 18:06:43 <mestery> Mostly, I wanted to document hte process elements here so things are written down and expectations are known 18:06:50 <anteaya> right 18:06:58 <anteaya> and I goal I stand behind 18:07:03 <mestery> thanks! 18:07:12 <anteaya> anyone willing to read this and give mestery some feedback on it? 18:07:24 <anteaya> doesn't have to be right now but maybe in the next two days? 18:07:25 <mestery> trinaths: Your input would be great here if you have time! 18:07:27 <sweston> I can volunteer for that 18:07:29 <krtaylor> mestery, I had seen the second page before, but I'll chime in 18:07:30 <mestery> sweston: thanks! 18:07:37 <mestery> krtaylor: perfect, thank you too! 18:07:37 <trinaths> mestery: neutron 3rd party testing links really helps in what is expected for a 3rd party CI testing 18:07:39 <anteaya> sweston krtaylor awesome 18:07:48 <lyxus> Most of the points make sense from my point of view. ie: provide logs, last timestamp, etc... The only input that I would have is to have a clear set of what kind of tests are required to be run 18:08:05 <mestery> lyxus: good input, thanks! 18:08:46 <anteaya> anyone have anything more at this time? 18:08:53 <lyxus> Maybe another one :) 18:08:57 <krtaylor> mestery, when I was doing my survey of third party documentation before summit, itwas one of the best I found, but I'll look at it in more detail 18:09:00 <anteaya> go ahead 18:09:39 <trinaths> mestery: [doubt] is that all the test cases be passed for a given patchset and change? 18:09:49 <luqas> also could be nice to have the link to the neutron 3rd party requirements on the general 3rd party page 18:09:54 <lyxus> The health of the CI is extremely important. There was an email this AM about the % success vs failure. could you clarifiy that ? 18:09:57 <mestery> trinaths: Yes, that would be the case I believe. 18:10:08 <anteaya> luqas: we don't have a general third party page yet, I am working on it 18:10:19 <anteaya> luqas: and yes once we have it, the links can be there 18:10:25 <lyxus> ie: does failure means voting -1 or wrongly reporting -1/+1 18:10:51 <trinaths> mestery: okay. 18:11:10 <mestery> lyxus: Understood, I'll clarfiy that, good input! 18:11:15 <anteaya> failure means build failure 18:11:20 <luqas> anteaya: I thought this one was the general http://ci.openstack.org/third_party.html 18:11:28 <anteaya> wrongly reporting means disagreement with jenkins 18:11:39 <anteaya> luqas: ah, I see what you mean 18:11:57 <anteaya> luqas: hmmmm, do feel free to offer a patch with that change and we can review it 18:12:12 <lyxus> anteaya, Not exaclty it could be an issue in the Third party infra that made a -1 where it should'nt be 18:12:17 <anteaya> I'm not saying yes or no right now, I would need to think about it and hear from others 18:12:36 <anteaya> lyxus: sorry I thought you were asking for definitions 18:12:58 <lyxus> i wasn't clear sorry ! 18:13:10 <anteaya> lyxus: if a third party ci system reported a failed build when they shouldn't what would be the situation? 18:13:27 <anteaya> 1) the third party ci is mailfuntioning 18:13:31 <luqas> well, it would be nice to have links to all the specifics for the different 3rd party components 18:13:35 <anteaya> 2) the third party ci is incorrect 18:13:43 <anteaya> what are the other posssiblities? 18:13:55 <anteaya> yes is would 18:14:09 <anteaya> part of the reason for these meetings is to deine all the things 18:14:15 <krtaylor> hm, maybe a terms/definitions section would be good for those starting out? 18:14:27 <anteaya> once we have defined all the things we can write them down and link to them 18:14:37 <anteaya> a good suggestion 18:14:38 <lyxus> I don't think so. I think it should be part of the metrics. (in my case, i don't do automatic -1, as i review them by hand ) 18:14:44 <luqas> sounds good to me 18:14:56 <anteaya> it would be good to have phrasing that we agree on defined 18:15:02 <trinaths> lyxus: failed, means [1] stack components did not start or [2] unable download the packages from internet - were there any thing you have noticed of build failure 18:15:21 <anteaya> lyxus: this is what I am asking you 18:15:33 <anteaya> lyxus: please expand on your perspective 18:15:41 <anteaya> I don't understand your point yet 18:16:42 <anteaya> I'm not saying you don't have a point, I'm saying I don't know what it is 18:16:47 <krtaylor> we should uncouple voting -1/+1 and failure maybe? 18:16:58 <anteaya> I agree 18:17:09 <anteaya> since failure and success are build outcomes 18:17:19 <krtaylor> one is potentially the result of the other 18:17:20 <krtaylor> yes 18:17:26 <trinaths> as I know, a ci build fails when [1] unable to download the packages from internet , [2] a stack service did not start or [3] a test completely fails. 18:17:29 <anteaya> potentially yes 18:17:42 <lyxus> I think i went to far on my idea. I was just wondering how we are going to measure the health of the CI. As long as we have clear requirements , I am fine with that. I just don't think that voting -1 should be part of the metrics 18:17:48 <anteaya> trinaths: those are the options I also am aware of 18:17:58 <anteaya> if there are others, I would like to know what they are 18:18:13 <krtaylor> trinaths, or, it could be a race condition, we see that often 18:18:16 <anteaya> lyxus: okay fair enough 18:18:44 <anteaya> lyxus: why do you feel voting -1 should not be part of the metrics? 18:20:33 <akerr> anteaya: it's possible someone commits code the legitimately breaks a driver. That's not a failure or instability of the ci system 18:20:43 <anteaya> akerr: right 18:20:53 <anteaya> that is one of the possible outcomes of testing 18:21:03 <akerr> -1 counting will give you a lot of red herrings if you use them to look for instability 18:21:09 <anteaya> and rather the point of the whole affair 18:21:33 <lyxus> anteaya, Voting -1 means that there is a problem with the dev code. As a dev, if i have a -1 it takes time to investigate it and see the issue. As the CI maintainer before doing a -1, i want to be sure that it is a real problem. This thing might take a bit 18:21:38 <anteaya> akerr: how do you propose we identify unstable systems? 18:21:52 <lyxus> anteaya, Don't get me wrong -1 are important. 18:21:55 <akerr> anteaya: I don't have a good answer for that, but I don't think -1 counting is the right way 18:21:57 <anteaya> lyxus: fair enough 18:22:14 <anteaya> lyxus: and if you need time to communicate that is fair 18:22:23 <anteaya> keep in mind this meeting is to share ideas 18:22:32 <anteaya> we have no authority to make decisions 18:22:40 <anteaya> decisions like with the programs 18:22:54 <anteaya> infra, neutron, nova, cinder, etc 18:23:00 <anteaya> we are here to share ideas 18:23:06 <krtaylor> agreed, but after discussing, we might be able to influence them a little bit 18:23:18 <krtaylor> eventually 18:23:30 <anteaya> akerr: okay, I'm open to hearing what you feel the right way is after you have had some time to give it some thought 18:23:34 <anteaya> sure 18:23:41 <anteaya> we can present good ideas 18:24:03 <anteaya> and improve documentation and disemmination of information 18:24:18 <anteaya> so any more on this topic today? 18:24:45 <lyxus> Not for me 18:24:48 <anteaya> great 18:24:52 <anteaya> let's move on 18:24:56 <anteaya> #topic Deadlines & Deprecations 18:25:06 <anteaya> mestery: anything for this topic today? 18:25:24 <mestery> anteaya: Nothing that isn't in the published wiki pages or the email I sent. 18:25:35 <anteaya> let's put it in the logs as well 18:25:36 <mestery> People ahve been very proactive about sending me emails, I need to reply and indicate they shoudl also copy the list. 18:25:44 <anteaya> in case people only read meeting logs 18:25:46 <mestery> OK 18:25:50 <anteaya> thanks 18:26:04 <mestery> The plan is to ensure all Neutron 3rd party CI systems are running by Juno-2. 18:26:16 <mestery> If they are not, we will take steps to remove code from the upstream tree. 18:26:27 <anteaya> awesome thank you 18:26:32 <mestery> I hope CI admins use this meeting to get help and work with the broader community before the deadline! 18:26:45 <anteaya> and you have at least two drivers slated for deprecation, yes? 18:26:51 <anteaya> mestery: thanks, me too 18:26:57 <mestery> Correct; Linuxbridge and OVS will be removed in Juno-2. 18:27:01 <anteaya> thanks 18:27:03 <mestery> ML2 is the replacement for both. 18:27:09 * anteaya nods 18:27:24 <anteaya> any other openstack program reps with deadlines or deprecations today? 18:27:45 <anteaya> moving on 18:27:49 <anteaya> #topic Highlighting a Program or Gerrit Account 18:28:04 <anteaya> #info How DriverLog can help tracking 3rd party CIs status 18:28:12 <anteaya> ilyashakhat__: is that your topic? 18:28:25 <ilyashakhat__> yep, i'm here to help) 18:28:29 <anteaya> great 18:28:31 <anteaya> welcome 18:28:39 <anteaya> let's start off with some background shall we 18:28:51 <anteaya> what is driverlog, and what is the current status? 18:29:52 <ilyashakhat__> DriverLog does 2 things: 1) it is a list of drivers 18:30:05 <anteaya> how is the list of drivers compiled? 18:30:18 <ilyashakhat__> 2) for drivers with enabled CIs it collects votes and shows their status 18:30:21 <anteaya> what files are scraped to arrive at the driverlog list? 18:30:36 <anteaya> let's start off with the list of drivers 18:30:42 <anteaya> how does that occur? 18:30:57 <trinaths> is DriverLog, active now. can we access it 18:31:02 <ilyashakhat__> the list was created manually and updated by community 18:31:18 <ilyashakhat__> trinaths: http://stackalytics.com/report/driverlog 18:31:35 <ilyashakhat__> the patches are accepted to project stackforge/driverlog 18:31:36 <anteaya> ilyashakhat__: where is the file containing the list so that people can file patches? 18:32:02 <ilyashakhat__> yes, https://github.com/stackforge/driverlog/blob/master/etc/default_data.json 18:32:41 <ilyashakhat__> for every driver it is possible to specify static list of versions, 18:32:59 <anteaya> okay so for drivers either present that shouldn't be or missing that should be there, folks can file patches to that file, correct? 18:33:00 <ilyashakhat__> or this list can be calculated by gerrit reviews 18:33:19 <anteaya> static list of versions 18:33:22 <ilyashakhat__> anteaya: correct 18:33:28 <anteaya> what do you mean, openstack release versions? 18:33:40 <ilyashakhat__> yes 18:33:42 <ilyashakhat__> https://wiki.openstack.org/wiki/DriverLog 18:33:44 <anteaya> okay great 18:34:03 <anteaya> anyone with any other questions about the list of drivers and how that is compiled? 18:34:04 <lyxus> ilyashakhat__, maintainers: is it the code maintainer or Ci maintainer. I assume also that you can have more than one maintainer. Seem to be a list 18:34:44 <ilyashakhat__> lyxus: maintainer = person who can respond to any questions regarding the driver 18:34:50 <ilyashakhat__> it is a list 18:34:59 <lyxus> ilyashakhat__, thank you 18:35:03 <anteaya> ilyashakhat__: how is the list of maintainers compiled? 18:35:08 <trinaths> ilyashakhat__, when can a unlisted driver be added, after CI is approved for voting ? 18:35:11 <anteaya> where did you get that information? 18:35:49 <ilyashakhat__> anteaya: just digging over wiki-pages :) 18:36:02 <anteaya> ilyashakhat__: hmmmm, not really a canonical list 18:36:19 <anteaya> for something as sdague rightly pointed out is consummed by the media 18:36:28 <ilyashakhat__> trinaths: you may add driver first and then update it with CI info 18:36:49 <anteaya> ilyashakhat__: so maintainers add their driver when they want to? 18:36:56 <ilyashakhat__> yes 18:36:59 <trinaths> ilyashakhat__, okay. it like git commit ? 18:37:00 <anteaya> no review of status for them to be added? 18:37:16 <anteaya> trinaths: it is a stackforge project 18:37:20 <ilyashakhat__> anteaya: what do you mean? 18:37:25 <anteaya> trinaths: it follows the openstack workflow 18:37:37 <trinaths> anteaya: okay thanks 18:37:39 <anteaya> ilyashakhat__: so the thing with anything with third party is status 18:37:45 <anteaya> readyness 18:37:49 <anteaya> stability 18:38:08 <anteaya> and third party vendors are motivated to say they are ready when they are not ready 18:38:20 <ilyashakhat__> having driver on the list doesn't mean it complies to 3rd-party requirements 18:38:30 <anteaya> like mestery's round up of third party ci system's for neutron has shown 18:38:40 <ilyashakhat__> in that case the will get red mark meaning they have no CI 18:38:43 <anteaya> ilyashakhat__: what does having a driver on the list mean? 18:39:02 <ilyashakhat__> it means that driver exists in the world 18:39:02 <anteaya> what is the meaning of having a driver on the list 18:39:06 <anteaya> does it 18:39:16 <anteaya> you just said it means they submitted a patch 18:39:22 <ilyashakhat__> aaa 18:39:29 <trinaths> ilyashakhat__,then it will be a big list, when driver is listed here, it may be within the CI requirements 18:39:40 <lyxus> ilyashakhat__, If i want to modify the default_data.json. Pull request is the way to go ? 18:40:04 <ilyashakhat__> lyxus: git review 18:40:12 <lyxus> ilyashakhat__, ok 18:40:19 <ilyashakhat__> it follows standard OpenStack process 18:40:35 <lyxus> ilyashakhat__, perfect ! 18:40:36 <trinaths> ilyashakhat__, i think, the drivers/ci need to added whe CI meets the requirements and is voting .. 18:40:37 <anteaya> so my point is that driverlog is estabilishing that it has no meaning 18:40:54 <anteaya> if it is just a place where vendors can shove code for marketers to consume 18:41:25 <ilyashakhat__> why? 'CI tested' column is the right place to look for drivers with CI enabled 18:41:32 <anteaya> ah yes 18:41:39 <anteaya> let's get to CI tested 18:41:57 <anteaya> which we already established last week on the ml doesn't actually mean tested 18:42:05 <anteaya> so let's look at that column 18:42:17 <anteaya> the entries for that column are two icons 18:42:17 <ilyashakhat__> yep, i think this needs to be fixed 18:42:24 <anteaya> am I correct so far? 18:42:37 <anteaya> a green check mark and an arrow of some kind 18:42:48 <anteaya> pointing from lower left to upper right 18:42:56 <anteaya> ilyashakhat__: is this accurate so far? 18:43:14 <ilyashakhat__> (arrow means that link will be opened in new tab) 18:43:17 <luqas> one thing is CI tested and another is that the CI fullfills the requirements 18:43:17 <ilyashakhat__> anteaya: yes 18:43:25 <ilyashakhat__> luqas: right 18:43:31 <luqas> so maybe another mark is needed 18:43:33 <anteaya> ilyashakhat__: okay what do the icons mean? 18:43:59 <ilyashakhat__> red means "no CI", green "CI is configured and has at least one vote" 18:44:06 <anteaya> red what? 18:44:07 <luqas> to tell if the CI is "certified" by OS 18:44:16 <anteaya> no certified 18:44:25 <anteaya> nothing is certified by anyone for any reason 18:44:30 <ilyashakhat__> luqas: don't use "certified" :) 18:44:36 <luqas> sorry 18:44:38 <luqas> :( 18:44:45 <anteaya> ilyashakhat__: so the check mark can be green or red? 18:44:46 <ilyashakhat__> red mark means that the driver has no CI 18:44:51 <anteaya> is that what you are say? 18:44:53 <ilyashakhat__> yes 18:45:01 <anteaya> what about the arrow 18:45:10 <anteaya> what colour choices does the arrow have 18:45:20 <ilyashakhat__> arrow is just a part of design 18:45:28 <anteaya> why have it? 18:45:36 <anteaya> what information is it conveying? 18:45:46 <ilyashakhat__> it means that the link will be opened in new tab 18:45:52 <anteaya> link to what? 18:45:57 <ilyashakhat__> web-link 18:46:02 <krtaylor> but what does CI tested really mean? just running tests? or tested to pass some level of requirements? 18:46:04 <anteaya> web-link to what? 18:46:18 <anteaya> krtaylor: so far it appears to mean they have a gerrit account 18:46:35 <ilyashakhat__> anteaya: to the latest review where the driver's CI ran 18:46:35 <luqas> which has voted at least once 18:46:36 <anteaya> green check mark is "gerrit account exists" 18:46:57 <ilyashakhat__> krtaylor: CI tested = just running tests 18:46:58 <anteaya> luqas: it could have voted on teh sandbox repo 18:47:08 <anteaya> luqas: that is useless information 18:47:15 <anteaya> ilyashakhat__: but it isn't 18:47:21 <krtaylor> then it shouldnt be called "tested" 18:47:30 <anteaya> right now all it is saying is the gerrit account exists 18:47:42 <anteaya> yes, I agree with krtaylor 18:47:45 <luqas> anteaya: then the vote on the sandbox repo shouldn't compute 18:47:51 <krtaylor> "CI running" would be more descriptive 18:47:57 <ilyashakhat__> ok, we can rename it 18:48:01 <anteaya> luqas: shouldn't and does are two different things 18:48:05 <anteaya> ilyashakhat__: please do 18:48:22 <ilyashakhat__> ok 18:48:23 <anteaya> ilyashakhat__: I'm not saying I disagree with the direction 18:48:35 <anteaya> I am saying taht you are currently conveying inaccurate information 18:48:51 <anteaya> in a field rife with inaccurate information 18:48:57 <krtaylor> ilyashakhat__, I'll patch today for PowerKVM, it was missed in the initial population 18:49:00 <ilyashakhat__> but we are community, and we can improve it :) 18:49:06 <krtaylor> anteaya, agreed 18:49:11 <anteaya> making it very very hard for people who want to do the right thing 18:49:34 <anteaya> ilyashakhat__: good, the first improvement is to cease conveying inaccurate information 18:49:39 <anteaya> as fast as you can 18:50:13 <anteaya> actually CI exists is the accurate discription of that column 18:50:36 <anteaya> since it isn't polling on current status of systems 18:50:55 <anteaya> and has green check marks for systems that haven't voted since februaruy 18:51:09 <krtaylor> anteaya, then can't it self populate from the CI group? 18:51:20 <anteaya> it doesn't seem to be doing so 18:51:26 <ilyashakhat__> if take only drivers with CIs, what kind of dashboard would you like to see? 18:51:34 <anteaya> I don't know what it can or can't do, I jsut know what it is doing 18:51:46 <anteaya> we need to move onto the next agenda item 18:52:04 <anteaya> ilyashakhat__: will you agree to rename that column from ci tested to ci exists? 18:52:17 <ilyashakhat__> anteaya: yes, I agree 18:52:25 <anteaya> and we can work on how to communicate other information on status 18:52:28 <anteaya> ilyashakhat__: thank you 18:52:42 <anteaya> #action ilyashakhat__ to rename driverlog ci tested? to ci exists 18:52:53 <anteaya> we can talk more about driverlog next week 18:52:56 <anteaya> fair enough? 18:53:21 <anteaya> okay I need to give trinaths some time 18:53:24 <anteaya> #info Discussion on Improving CI performance and Multi Node setup (trinaths) 18:53:29 <anteaya> trinaths: you're up 18:53:33 <trinaths> yes 18:53:54 <anteaya> what is on your mind 18:54:26 <trinaths> with my CI, I see that it takes about an hour for a build to complete. any ideas on lowering the test run time 18:54:43 <anteaya> trinaths: builds on infra take about an hour 18:54:55 <anteaya> so the build time on your system is about the same as infra 18:55:06 <sweston> that's a good metric 18:55:06 <anteaya> depends on what tests you are running 18:55:13 <anteaya> what tests are you running? 18:55:18 <trinaths> getting all the openstack components from git take much time 18:55:25 <sweston> can that be posted somewhere .. a lot of people ask about that 18:55:28 <anteaya> how much time? 18:55:38 <anteaya> sweston: sure, where do you suggest? 18:55:45 <trinaths> as suggested in Neutron3rdParty testing linl 18:56:10 <anteaya> mestery: any objection to adding that metric to the neutron third party wiki page? 18:56:11 <sweston> anteaya: possibly a wiki 18:56:40 <mestery> anteaya: I think adding that metric would be fine. 18:56:46 <anteaya> great thanks 18:56:47 <trinaths> is that longer time for a build a fault with my CI, any suggestions on improvement 18:56:47 <lyxus> I have cut down a lot of the building time by having a local pypi and having part some of the ubuntu packgages installed. 18:56:58 <anteaya> trinaths: do you want to add that and sweston can you review his changes? 18:57:15 <anteaya> lyxus: great, have you documented your process anywhere? 18:57:17 <sweston> anteaya: glad to 18:57:21 <anteaya> on a blog post perhaps? 18:57:29 <anteaya> sweston: thanks 18:57:33 <lyxus> anteaya, I can write something if you want to 18:57:40 <trinaths> what changes ? 18:57:42 <anteaya> lyxus: that would be great if you could 18:57:57 <lyxus> anteaya, I will do that. 18:58:03 <anteaya> lyxus: thanks 18:58:12 <anteaya> and you can add the url to next week's meeting 18:58:22 <anteaya> and we can applaud in gratitude 18:58:24 <anteaya> :D 18:58:40 <sweston> anteaya: yw 18:58:55 <lyxus> We'll see :) I will write it this week. 18:58:56 <anteaya> trinaths: do you want to add the information that it takes about an hour to run a build to the neutron wikipage? 18:59:05 <anteaya> trinaths: sweston is willing to help you 18:59:13 <anteaya> lyxus: awesome thank you 18:59:19 <anteaya> we are out of time 18:59:38 <anteaya> sorry if I didn't get to your item, please add it to next week's agenda 18:59:39 <trinaths> anteaya, sure. sweston help may solve the problem 18:59:43 <anteaya> thanks for a great meeting 18:59:44 <krtaylor> good meeting! 18:59:48 <anteaya> see you next week 18:59:51 <lyxus> thanks ! 18:59:51 <trinaths> by 18:59:52 <anteaya> #endmeeting