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