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