18:00:20 <anteaya> #startmeeting third-party 18:00:20 <openstack> Meeting started Mon Aug 25 18:00:20 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:23 <openstack> The meeting name has been set to 'third_party' 18:00:29 <anteaya> and we're off 18:00:36 <anteaya> who's here? 18:00:38 <dougwig> o/ 18:00:40 <asselin> hi 18:00:44 <dane_leblanc> o/ 18:00:45 <daya_k> hi 18:00:45 <krtaylor> anteaya, is punctual! 18:00:50 <krtaylor> o/ 18:01:02 <songole> hi 18:01:11 <anteaya> welcome everyone 18:01:14 <anteaya> krtaylor: I do try 18:01:20 <krtaylor> hi anteaya 18:01:32 <anteaya> #topic Welcome & Reminder of OpenStack Mission 18:01:45 <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:01:50 <bmwiedemann> o/ 18:02:04 <anteaya> the mission is the reason we are all here, for those who are new or like the reminder 18:02:15 <anteaya> here is our agenda 18:02:19 <anteaya> #link https://wiki.openstack.org/wiki/Meetings/ThirdParty#Agenda_for_next_meeting 18:02:34 <anteaya> #topic Review of previous week's open action items 18:02:51 <anteaya> we had some 18:02:56 <anteaya> #info third party team to review https://review.openstack.org/#/c/99990/ 18:02:57 <jungleboyj> o? 18:03:00 <salv-orlando> aloha 18:03:01 <jungleboyj> o/ 18:03:11 <anteaya> we still can stand some more eyes on that one 18:03:28 <anteaya> that is the infra-spec that will outline all the puppet module work 18:03:42 <anteaya> making it easier for folks to consume the infra tooling 18:03:53 <mestery> o/ 18:03:56 <anteaya> so it gets another action item 18:04:02 <anteaya> #action third party team to review https://review.openstack.org/#/c/99990/ 18:04:12 <anteaya> next one 18:04:12 <esmute> o/ 18:04:16 <anteaya> #info anteaya to offer joa's work as config patches with joa as co-author by next meeting 18:04:20 <anteaya> I didn't do that 18:04:22 <anteaya> bad me 18:04:27 <anteaya> for next week again 18:04:30 <anteaya> #action anteaya to offer joa's work as config patches with joa as co-author by next meeting 18:04:43 <anteaya> #info asselin to ask infra about zuul configration to filter patches 18:04:54 <anteaya> that was in relation to the next item 18:05:05 <anteaya> #info asselin to reply to http://lists.openstack.org/pipermail/openstack-dev/2014-August/043392.html with what he learns 18:05:09 <asselin> yes, fungi replied to the e-mail 18:05:14 <anteaya> great 18:05:23 <anteaya> well thanks for stepping up to the task anyway 18:05:27 <anteaya> I'm grateful 18:05:41 <anteaya> was fungi's email helpful to answering your questions as well, asselin? 18:05:47 <asselin> yes, always 18:05:52 <anteaya> great 18:06:15 * fungi is pleased to be of some help 18:06:18 <anteaya> that's it for last weeks action items 18:06:21 <anteaya> thanks fungi 18:06:27 <anteaya> #topic Announcements 18:06:37 <anteaya> #info Use the ThirdPartySystems wiki page to notify changes in status 18:06:46 <anteaya> #link https://wiki.openstack.org/wiki/ThirdPartySystems 18:06:54 <anteaya> let's take a peek shall we? 18:07:09 <krtaylor> I tried and tried to get an individual cell to change color 18:07:15 <anteaya> do you see the fourth bulled point? 18:07:38 <krtaylor> but there is a workaround 18:07:45 <anteaya> does anyone not understand how to change your cell colour and icon if you need to notify others of a change in status? 18:08:00 <anteaya> krtaylor: the cell has a changed background colour 18:08:28 <krtaylor> anteaya, what we discussed was to show red/yellow/green 18:08:36 <krtaylor> but this does show that a system is down 18:08:42 <anteaya> #link https://wiki.openstack.org/wiki/Template:ThirdPartySystemTableEntryDown 18:08:49 <krtaylor> I'd still like to be able to pass color to the template 18:08:53 <krtaylor> but it discards it 18:09:03 <anteaya> krtaylor: play away with templates and colours if you want 18:09:25 <krtaylor> anteaya, I have read and tried just about everything 18:09:32 <krtaylor> I need a guru at this point 18:09:37 <anteaya> that line in that template successfully colours the background 18:09:40 <anteaya> does it not? 18:09:44 * anteaya refreshes 18:09:56 <krtaylor> until we geta status dashboard, I think it is more effort than it is worth 18:10:07 <anteaya> okay 18:10:11 <anteaya> so for everyone else 18:10:13 <krtaylor> yes, it is a suitable workaround 18:10:36 <anteaya> do you understand how to communicate that your ci is down for whatever reason by reading bullet point four on the wikipage? 18:10:54 <anteaya> btw I interpret silence as no with this group 18:11:06 <krtaylor> you is everyone in this case, right? 18:11:10 <daya_k> yes, got it, can we use it if it is reporting failures due to setup issues 18:11:21 <anteaya> krtaylor: yes you == everyone 18:11:42 <bmwiedemann> yes, understood 18:11:50 <dougwig> yes, looks straight forward 18:11:52 <anteaya> daya_k: yes, or actually if you have turned off your ci account because it is reporting failures due to setup issues 18:12:02 <anteaya> bmwiedemann dougwig great thanks 18:12:22 <anteaya> if your system is failing to build, turn it off, and update the wikipage to say your system is off 18:12:37 <daya_k> anteaya: ok thanks 18:12:51 <anteaya> if your system is failing to build and you don't turn it off, infra will turn it off which is tougher for you to get it turned back on 18:12:58 <anteaya> daya_k: great thanks 18:13:18 <anteaya> please spread the word and help others use this feature as intended 18:13:31 <asselin> one way to 'turn off' is to use the silent pipeline: http://lists.openstack.org/pipermail/openstack-dev/2014-August/043876.html 18:13:32 <daya_k> anteaya : will this be done even if we dont vote, our system reports 0 on failure, and +1 on success 18:13:34 <krtaylor> I just did to show a real example 18:13:47 <asselin> this way you're is still 'on', but just not reporting to gerrit 18:14:02 <daya_k> asselin: thanks, saw that note earlier, thats a good idea 18:14:23 <anteaya> fungi: did you want third party ci to use the silent pipeline? 18:14:27 <anteaya> fungi: this is news to me 18:14:33 <anteaya> fungi: care to clarify? 18:14:49 <dougwig> for us third-party people, it's probably simpler to comment out the success/failure clauses on our check pipelines and reload zuul, than two have multiple pipelines. 18:14:58 <fungi> anteaya: why would i/we care if a third party uses the silent pipeline on their zuul server to prevent them from commenting on changes? 18:14:59 <anteaya> daya_k: any system that is failing to build due to set up issues should be turned off 18:15:00 <dougwig> /two/to/ 18:15:22 <anteaya> daya_k: you should use teh sandbox repo to test unstable systems until your system can build reliably 18:15:34 <fungi> anteaya: jobs in a silent pipeline in zuul won't add comments to gerrit changes 18:15:36 <anteaya> fungi: "on their zuul server" 18:15:41 <anteaya> fungi: great, thank you 18:15:49 <asselin> dougwig, the advantage of the silient pipeline is you can 'turn off' only those jobs that are unstable. the others that are working can continue. 18:15:59 <dougwig> sure, but i only have one job. :) 18:15:59 <daya_k> anteaya: sounds good 18:16:25 <anteaya> asselin: yes as long as your system is not creating noise by commenting on gerrit patches, use what works 18:16:33 <anteaya> we recommend the sandbox repo 18:16:45 <fungi> well, to "turn off" a job you just remove it from the layout entirely. moving it to the silent pipeline allows you to keep running it and generating logs but keeps it from reporting into gerrit 18:17:02 <anteaya> if you do other things, ensure there is no ramifications on our gerrit 18:17:07 <fungi> which can be helpful for debugging, depending on your needs 18:17:09 <asselin> ok, silent pipeline is a nice tool in the toolbox for 3rd party ci folks. 18:17:22 <anteaya> which as fungi points out, is the case with the silent pipeline 18:17:38 <anteaya> great 18:17:41 <anteaya> more here? 18:17:57 <anteaya> next 18:18:04 <anteaya> #info We have two new mailing lists, please subscribe (anteaya) 18:18:21 <anteaya> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/third-party-request 18:18:33 <anteaya> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/third-party-announce 18:18:52 <anteaya> so in order to reduce noise in other areas these two new mailing lists have been created 18:18:59 <anteaya> please subscribe to both 18:19:17 <dougwig> why would non-infra need to be subscribed to -request? 18:19:18 <anteaya> they are new and I have never admined an email list before so I have to learn 18:19:23 <anteaya> I will make mistakes 18:19:38 <anteaya> hopefully in a week or so I will get the hang of it 18:19:55 <anteaya> dougwig: don't you want to be able to help out where you are able? 18:20:31 <dougwig> i'm talking in general. note that i asked that before you clarified. 18:20:33 <anteaya> like in being able to interact with a new account requester to ensure the request is accurate and perhaps invite them to the third party meeting? 18:20:45 <anteaya> dougwig: noted 18:21:14 <anteaya> I am hoping that this group becomes self-sustaining and I can move onto other things eventually 18:21:25 <anteaya> I am trying to train you to lead 18:21:38 <anteaya> the group of you 18:21:53 <anteaya> my wish is for you to be able to not need me at some point 18:21:58 <anteaya> and you can self govern 18:22:11 <anteaya> so mailing lists 18:22:13 <anteaya> questions? 18:22:16 <krtaylor> anteaya, we will always need you :) 18:22:30 <anteaya> oh don't say that 18:22:35 <anteaya> I am so replaceable 18:22:35 <krtaylor> hehheh 18:22:36 <bmwiedemann> for always < 50y 18:22:47 <anteaya> it is nece to be welcomed but I don't like being needed 18:22:57 <anteaya> so next topic 18:23:02 <anteaya> #topic OpenStack Program items 18:23:14 <anteaya> #info Update from Cinder Mid-Cycle Meet-up (jungleboyj) 18:23:19 <anteaya> jungleboyj: you're up 18:23:29 <jungleboyj> anteaya: Ok. 18:23:54 <jungleboyj> So, we had our mid-cycle meet-up two weeks ago in Ft. Collins, CO. 18:24:08 <jungleboyj> Was our first as a Cinder group f2f . 18:24:24 <jungleboyj> Ended up being very valuable. https://etherpad.openstack.org/p/cinder-meetup-summer-2014 18:24:37 <anteaya> #link https://etherpad.openstack.org/p/cinder-meetup-summer-2014 18:24:53 <jungleboyj> We had anteaya there and her assistance with CI and process items was great. 18:25:10 <anteaya> you are too kind 18:25:42 <jungleboyj> Big takeaways were the fact that there are issues with getting CI running on Fibre Channel storage that non-storage people may not have been aware of. 18:25:51 <anteaya> yes 18:26:01 <jungleboyj> We are working that, but it may take a little longer to get those systems running CI. 18:26:27 <anteaya> as long as folks are keeping in touch with you or DuncanT on that 18:26:28 <jungleboyj> The fact that we would like to get something of a results dashboard going to show how CI's are running over time. 18:26:57 <jungleboyj> anteaya: We should be good there. I am one of the ones effected. 18:26:57 <anteaya> #link https://review.openstack.org/#/c/114315/ 18:27:14 <anteaya> that is the creation of the repo we discussed, it is waiting on a new patchset from me 18:27:20 <anteaya> jungleboyj: great 18:27:43 <anteaya> the above patchset creates a new repo for a dashboard for ci 18:27:47 <jungleboyj> Was also a good opportunity for each CI group to share our different approaches to getting CI setup. I think that was hepful. 18:28:03 <anteaya> the code needs some work but it is a start 18:28:09 <anteaya> jungleboyj: agreed 18:28:23 <anteaya> jungleboyj: any code urls from that yet? 18:28:34 <jungleboyj> I think that pretty much covers the highlights. 18:28:40 <anteaya> jungleboyj: great 18:28:47 <jungleboyj> code urls from what? 18:29:01 <anteaya> jungleboyj: from folks going to share their tools and approaches 18:29:15 <anteaya> I know DuncanT had some ideas and thingee had some thoughts 18:29:32 <anteaya> have they shared code yet ready for more eyes yet? 18:29:34 <jungleboyj> Oh, yes, DuncanT has a KISS set of scripts for CI. 18:29:39 <anteaya> great 18:29:50 <anteaya> let us know when he is ready to share 18:30:08 <anteaya> anything else then? 18:30:17 <jungleboyj> He shared this at last week's Cinder meeting: https://github.com/Funcan/kiss-ci 18:30:36 <anteaya> #link https://github.com/Funcan/kiss-ci 18:30:40 <anteaya> jungleboyj: great thank you 18:30:48 <jungleboyj> He said comments are welcome. Or do with it as you need. :-) 18:31:05 <anteaya> so take a look, it isn't supported by infra just be aware 18:31:08 <anteaya> jungleboyj: thank you 18:31:14 <krtaylor> there are several other attempts to simplify CI as well 18:31:15 <jungleboyj> anteaya: You are welcome. 18:31:20 <anteaya> :D 18:31:21 <DuncanT> I've some updates from JohnGriffith that should make them better, I'm just working on merging them in 18:31:30 <krtaylor> I have noted them in past meeting logs 18:31:31 <anteaya> DuncanT: thanks for the update 18:31:31 <jungleboyj> DuncanT: +2 18:31:50 <anteaya> krtaylor: perhaps I have missed them 18:32:12 <anteaya> more here or move on? 18:32:21 * krtaylor goes to find them 18:32:24 <anteaya> kk 18:32:28 * anteaya waits 18:32:36 <krtaylor> np, move forward 18:32:41 <anteaya> okay moving on 18:32:46 <anteaya> #topic Deadlines & Deprecations 18:33:11 <anteaya> so cinder, jungleboyj DuncanT any deadlines or depreactions to discuss? 18:33:35 <jungleboyj> DuncanT: I defer to you. Have you started sending out nasty grams ? 18:34:02 <anteaya> while we wait for DuncanT's reply, Neutron mestery same question 18:34:18 <anteaya> mestery: deadlines or deprecations from Neutron to discuss? 18:34:18 <DuncanT> No, they're on hold pending a satisfactory set of docs 18:34:28 <anteaya> DuncanT: very good, keep us informed 18:34:41 <anteaya> anyone representing Nova today? 18:35:10 <anteaya> salv-orlando: if mestery is tied up, anything you know of for deadlines and deprecations from Neutron? 18:35:33 <salv-orlando> anteaya: for plugins and drivers? 18:35:38 <anteaya> salv-orlando: yes 18:35:46 * salv-orlando one sec 18:35:51 * anteaya waits 18:36:01 <mestery> anteaya: No deadlines, deprecations are already announced: 18:36:15 <mestery> anteaya: Mellanox plugin, Ryu Plugin, and Cisco Nexus sub-plugin are deprecated in Juno 18:36:24 <anteaya> mestery: great thanks 18:36:31 <mestery> anteaya: Sure! 18:36:34 <anteaya> and a link to that announcement? 18:36:36 <salv-orlando> thanks mestery I did not have the list at hands 18:36:37 <anteaya> for the logs? 18:36:47 <anteaya> salv-orlando: thanks for looking anyway 18:36:48 <mestery> anteaya: Getting it ... 18:36:52 <anteaya> mestery: thanks 18:37:09 <anteaya> any other OpenStack program represented today that I haven't mentioned? 18:37:28 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/042790.html Ryu Plugin Deprecation 18:38:12 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/043559.html Mellanox Plugin Deprecation 18:38:15 <anteaya> great thank you 18:39:00 * anteaya waits for one more link 18:39:19 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/042765.html Cisco Plugin Deprecation 18:39:21 <mestery> anteaya: Done :) 18:39:24 <anteaya> thanks 18:39:30 <anteaya> next topic 18:39:36 <anteaya> #topic Highlighting a Program or Gerrit Account 18:39:50 <anteaya> #info How to vote when blocked by un-merged fixes or HW-enabling commits (dane_leblanc) 18:39:56 <anteaya> dane_leblanc: your floor 18:40:00 <dane_leblanc> Thanks! 18:40:10 <dane_leblanc> I don't know if this was discussed before 18:40:20 * mestery listens in here. 18:40:22 <anteaya> don't worry charge ahead 18:40:26 <dane_leblanc> But I was wondering if there's a prescribed way to handle the corner case 18:40:38 <anteaya> please describe the corner case 18:40:44 <dane_leblanc> Where our CI is blocked on a critical bug which is not yet merged 18:40:45 <anteaya> so far I am not understanding 18:40:52 <anteaya> do we have an example? 18:40:58 <dane_leblanc> Or it could be that we have a plugin just being introduced 18:41:08 <dane_leblanc> and the HW-enablement commits have not been merged 18:41:16 <anteaya> what is HW- 18:41:37 <dane_leblanc> In this case, any change sets outside of the changes with these enablements (or fixes) will fail in the CI 18:41:46 <dane_leblanc> HW is a switch,let's say 18:41:47 <dougwig> (hardware) 18:41:53 <anteaya> ah okay thanks 18:41:59 <dane_leblanc> Sorry for the acronym 18:42:00 * anteaya hates acronyms 18:42:03 <anteaya> np 18:42:05 <dougwig> AHA 18:42:22 <dane_leblanc> So, the question is how to vote on the other change sets which we know would fail 18:42:23 * dougwig ducks 18:42:39 <anteaya> dane_leblanc: so is this a dependency issue? 18:42:53 <anteaya> as in a patch is dependent on another patch? 18:43:07 <dane_leblanc> Yes, dependency on a fix, 18:43:19 <anteaya> is carl_baldwin around? 18:43:20 <bmwiedemann> anteaya: but every patch is dependent on the one fix 18:43:31 <dane_leblanc> But there's no way we can make every patch dependent 18:43:36 <anteaya> bmwiedemann: yes, that is what I am hearing 18:43:49 <carl_baldwin> anteaya: I’m around 18:43:50 <anteaya> dane_leblanc: do we have an example of this in action? 18:43:52 <dane_leblanc> So we would like to abstain from voting 18:43:54 * carl_baldwin goes to read context 18:43:56 <anteaya> carl_baldwin: great, thanks 18:44:13 <anteaya> carl_baldwin: do you remember at sprint we discussed a testing system you had internally 18:44:16 <dane_leblanc> Yes, 1 example is a plugin we're just introducing 18:44:38 <anteaya> carl_baldwin: where there was a spider web of patches that your system had to pull in in the right order to test everything 18:44:46 <anteaya> carl_baldwin: do you recall that chat? 18:44:54 <carl_baldwin> anteaya: Yes, I recall that chat. 18:45:12 <anteaya> carl_baldwin: you were going to try to make that available to the public 18:45:19 <carl_baldwin> DVR was implemented in a non-linear chain of dependencies. 18:45:22 <anteaya> carl_baldwin: what is the status on that direction 18:45:39 <anteaya> dane_leblanc: do you have a url for your plugin you are introducing? 18:45:43 <dane_leblanc> But won't this be frought with merge conflicts, if we're doing this on every patch? 18:45:57 <anteaya> dane_leblanc: I can't answer that question 18:46:04 <dougwig> an example (forward search for 'only relevant pre-merge'): https://github.com/dougwig/neutron-thirdparty-ci/blob/master/ci-slave-post-devstackin a more complicated change, there might be common files edited, which would lead to merge madness. 18:46:10 <carl_baldwin> anteaya: I have not made any progress on making that public. However, the script I hacked out *seemed* to work well and anyone is welcome to it. 18:46:13 <anteaya> dane_leblanc: I need to see something as an example 18:46:21 <dougwig> borked the link: https://github.com/dougwig/neutron-thirdparty-ci/blob/master/ci-slave-post-devstack 18:46:36 <dane_leblanc> An example is the plugin for our APIC controller hardware 18:46:40 <anteaya> carl_baldwin: have you a url for that code? (and have you licenced it?) 18:46:52 <dane_leblanc> The CI testbed includes this hardware 18:47:00 <carl_baldwin> anteaya: No, neither yet. 18:47:04 <anteaya> #link https://github.com/dougwig/neutron-thirdparty-ci/blob/master/ci-slave-post-devstack 18:47:13 <dane_leblanc> But the hardware won't work without initial commits which have not been approved and merged 18:47:17 <anteaya> carl_baldwin: okay, do update me when you are able 18:47:21 <anteaya> carl_baldwin: thanks 18:47:43 <dane_leblanc> We need to keep testing the initial commits as their being reviewed 18:47:54 <anteaya> dane_leblanc: do you have the url for the initial commits for this plugin? 18:47:56 <dane_leblanc> But all other patches will fail because they don't contain our initial commits 18:48:37 <dane_leblanc> https://review.openstack.org/#/c/111431/ 18:48:52 <anteaya> #link https://review.openstack.org/#/c/111431/ 18:48:55 <anteaya> dane_leblanc: thanks 18:49:02 <dane_leblanc> https://review.openstack.org/#/c/111432/ 18:49:08 <dane_leblanc> There are 3 others 18:49:26 <anteaya> the commit message says enhancements 18:49:37 <anteaya> is this the inital commit for a driver? 18:49:41 * anteaya is confused 18:49:49 <dane_leblanc> Ah, sorry 18:49:56 <dane_leblanc> I'm confusing 2 situations 18:50:04 <anteaya> let's stay with one plesae 18:50:10 <dane_leblanc> 2 different plugins, but similar issue 18:50:11 <anteaya> I'm having a hard enough time with one 18:50:16 <dane_leblanc> With APIC 18:50:25 <anteaya> let's select an example and walk through it 18:50:28 <dane_leblanc> (same one we've been disussing) 18:50:40 <anteaya> what is APIC? 18:50:46 <anteaya> #link https://review.openstack.org/#/c/111432/ 18:50:47 <dane_leblanc> There is a bug where all patch sets out of this list will cause leakage 18:50:54 <dane_leblanc> In our hardware in the CI 18:51:06 <anteaya> is there a fix for the bug? 18:52:13 <dane_leblanc> It's not a fix per se, but the new set of enhancements are the only way of being compatible with the new APIC that's in the CI 18:52:42 <dane_leblanc> The APIC was updated recently, and old plugin code is incompatible 18:52:44 <anteaya> okay I think we have moved from the generality of third party to the specifics of this situation 18:53:03 * anteaya still doesn't know what APIC stands for, but is willing to move on 18:53:03 <dane_leblanc> But this is a general situatoin. 18:53:14 <anteaya> anyone else had this situation? 18:53:15 <bmwiedemann> anteaya: a special computer chip 18:53:20 <anteaya> show of hands will work 18:53:23 <anteaya> bmwiedemann: thanks 18:53:25 <kevinbenton> anteaya: sort of. 18:53:32 <anteaya> kevinbenton: thanks for speaking up 18:53:35 <anteaya> anyone else? 18:53:46 <dougwig> i did, but it was a trivial case, and easily worked around. 18:53:55 <dane_leblanc> APIC = Application Policy Infrastrucure Controller 18:53:55 <anteaya> okay let's dig in 18:54:08 <anteaya> kevinbenton: what did you do when faced with this? 18:54:13 <dane_leblanc> anteaya, there's a more general case which other people might see 18:54:24 <anteaya> dane_leblanc: do expand on that point 18:54:39 <dane_leblanc> Let's say someone is introducing a new plugin 18:54:41 <kevinbenton> anteaya: i mentioned this on the mailing list, but we have a script that checks for certain conditions before voting 18:54:44 <dane_leblanc> For some new hardware 18:55:00 <anteaya> kevinbenton: is your script available to others? 18:55:00 <dane_leblanc> When we first start up the CI for this new plugin 18:55:03 <kevinbenton> anteaya: so we don’t vote if a patch is known to be broken with our CI for some reason 18:55:18 <kevinbenton> anteaya: no, it’s a really hacky bash script right now that checks for certain files, commit IDs, etc 18:55:38 <anteaya> kevinbenton: it sounds like a helpful concept, hacky though it might be 18:55:56 <anteaya> kevinbenton: are you willing to have it on stackforge so that others may use it and offer patches? 18:56:32 <kevinbenton> anteaya: possibly, but i wouldn’t be able to get to it for a couple of weeks 18:56:45 <dane_leblanc> Is not voting the best choice, versus a "SKIPPED" vote? 18:56:52 <kevinbenton> anteaya: the patch alone doesn’t make much sense, i would want to document how our CI works to see how it’s called 18:57:08 <anteaya> kevinbenton: if you are able to make the script available by public url, I can write the patch that creates the repo 18:57:19 <anteaya> kevinbenton: that is fair 18:57:28 <anteaya> dane_leblanc: a good question 18:57:33 <anteaya> what do others think? 18:57:34 <dane_leblanc> "SKIPPED" might be more transparent, saying that "we see your patch, but can't test it now" 18:57:37 <kevinbenton> dane_leblanc: skipped 18:57:56 <anteaya> one vote for skipped, anyone else? 18:58:01 <dane_leblanc> skipped 18:58:13 <anteaya> any other opinions here? 18:58:21 <dane_leblanc> It would be good to have kevinbenton's solution on the wiki page for how to do CI 18:58:25 <dane_leblanc> as a hint 18:58:43 <anteaya> yes, being able to see this as an option would be good 18:58:50 <dane_leblanc> I was stuck on how to do this in a zuul/jenkins setup 18:58:55 <kevinbenton> dane_leblanc: i’m not sure how well it integrates with the zuul approach though 18:59:01 <anteaya> moving to Open Discussion 18:59:03 <dane_leblanc> Right 18:59:12 <dane_leblanc> The zuul/jenkins needs a different solution 18:59:18 <anteaya> #topic Open Discussion 18:59:24 <anteaya> 40 seconds 18:59:33 <anteaya> anyone with anything? 18:59:46 <anteaya> okay, great meeting everyone 18:59:47 <daya_k> has anyone gotten swift upload to work from zuul.conf settings? 19:00:02 <NobodyCam> wow not a lot of Open Discussion time 19:00:09 <anteaya> not today, no 19:00:12 <NobodyCam> lol :) 19:00:18 <anteaya> be sure to put agenda items on the agenda 19:00:23 <anteaya> time to wrap up 19:00:25 <daya_k> np, i will bring up on other forums 19:00:31 <anteaya> thanks everyone, see you next week 19:00:34 <anteaya> #endmeeting