08:27:08 <abadger1999> #startmeeting Ansiblefest London
08:27:08 <zodbot> Meeting started Wed Jun 21 08:27:08 2017 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:27:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
08:27:08 <zodbot> The meeting name has been set to 'ansiblefest_london'
08:28:07 <thaumos> @abadger1999 is in control!
08:28:19 <abadger1999> #chair jimi|ansible misc j00bar nitzmahone gregdek gundalow thaumos dag_ jlk mikedlr rbergero1
08:28:19 <zodbot> Current chairs: abadger1999 dag_ gregdek gundalow j00bar jimi|ansible jlk mikedlr misc nitzmahone rbergero1 thaumos
08:28:28 <abadger1999> The power is yours!
08:28:41 <thaumos> come on @abadger1999 yell it out He-man style
08:28:49 <thaumos> I HAVE THE POWER
08:28:49 <jimi|ansible> by the power of zodbot!
08:29:06 <abadger1999> He-man vs Captain Planet.  Fight!
08:29:54 <square1> ahem :)
08:31:09 <jimi|ansible> still trying to get audio working for the conference...
08:31:21 <square1> I can hear something :)
08:31:33 <jimi|ansible> is it gundalow doing tests?
08:31:51 <jimi|ansible> it may be that they're having trouble getting it routed to the speakers in the room
08:34:34 <abadger1999> It's trouble getting it routed to the bluejeans of course.
08:35:03 <square1> it was working a minute ago
08:36:33 <abadger1999> #topic Ansiblefest London:  Agenda:  https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-agenda
08:36:39 <gundalow> abadger1999: can haz chair
08:36:45 <gundalow> oh, you have
08:36:54 <abadger1999> Hello everyone!
08:36:59 <willthames> hi Toshio
08:37:01 <akasurde> Hello Everyone
08:37:04 <jborean93> hey
08:37:04 <dag> o/
08:37:06 * jimi|ansible waves
08:37:08 <jlk> o/
08:37:11 <abadger1999> #chair willthames akasurde jborean93
08:37:11 <zodbot> Current chairs: abadger1999 akasurde dag_ gregdek gundalow j00bar jborean93 jimi|ansible jlk mikedlr misc nitzmahone rbergero1 thaumos willthames
08:37:11 <square1> hey :)
08:37:12 <fale> o/
08:37:17 <gundalow> #info Agenda https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-agenda
08:37:18 <abadger1999> #chair square1 fale
08:37:18 <zodbot> Current chairs: abadger1999 akasurde dag_ fale gregdek gundalow j00bar jborean93 jimi|ansible jlk mikedlr misc nitzmahone rbergero1 square1 thaumos willthames
08:37:19 <ttomecek> ó/
08:37:26 <abadger1999> #chair ttomecek
08:37:26 <zodbot> Current chairs: abadger1999 akasurde dag_ fale gregdek gundalow j00bar jborean93 jimi|ansible jlk mikedlr misc nitzmahone rbergero1 square1 thaumos ttomecek willthames
08:37:50 <mordred> ô/
08:38:05 <abadger1999> #chair trishnag mordred
08:38:05 <zodbot> Current chairs: abadger1999 akasurde dag_ fale gregdek gundalow j00bar jborean93 jimi|ansible jlk mikedlr misc mordred nitzmahone rbergero1 square1 thaumos trishnag ttomecek willthames
08:38:26 <trishnag> o/
08:38:45 <abadger1999> #info Blue jeans (video conference) meeting link: https://bluejeans.com/3008457278/
08:38:46 <flaper87> o/
08:39:02 <abadger1999> #chair trishnag flaper87
08:39:02 <zodbot> Current chairs: abadger1999 akasurde dag_ fale flaper87 gregdek gundalow j00bar jborean93 jimi|ansible jlk mikedlr misc mordred nitzmahone rbergero1 square1 thaumos trishnag ttomecek willthames
08:39:16 <abadger1999> #topic Summary of work accomplished since last year
08:39:35 <abadger1999> #info New irc channels for vmware and windows
08:39:37 <square1> don't forget #ansible-windows!
08:39:45 <abadger1999> #info core extras merge
08:39:58 <j00bar> don't forget #ansible-container either
08:40:19 <abadger1999> #info ansible-container irc channel as well
08:40:21 <abadger1999> #topic contributor docs
08:40:38 <abadger1999> #info gundalow spearheading putting all the documentation for contributing into one place.
08:41:11 <abadger1999> greg saying that there are many things that make it hard to figure out how to contribute to ansible.
08:41:25 <jimi|ansible> core engine deep dive documentation: https://github.com/ansible/ansible/commit/fa31043e7ee2a9fc74ccc39ddeb43587c2fea6d3
08:41:31 <abadger1999> Contribution mechanisms have grown ad hoc as we add new things (like ansibullbot)
08:41:57 <abadger1999> So first simple step is to look at all the documentation and putting it into a single place so there's a one-stop-shop
08:42:26 <gundalow> Docs are currently spread around multiple places and don't link. The plan is to get the docs all into one place
08:42:32 <abadger1999> We "sorta have processes for some of these but they're scattered all over the place."
08:42:43 <pabelanger> ohai
08:42:46 <abadger1999> #info core engine deep dive documentation: https://github.com/ansible/ansible/commit/fa31043e7ee2a9fc74ccc39ddeb43587c2fea6d3
08:43:00 <abadger1999> #chair pabelanger
08:43:00 <zodbot> Current chairs: abadger1999 akasurde dag_ fale flaper87 gregdek gundalow j00bar jborean93 jimi|ansible jlk mikedlr misc mordred nitzmahone pabelanger rbergero1 square1 thaumos trishnag ttomecek willthames
08:43:32 <rbergero1> #link https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-core
08:43:34 <hyperized> maybe also include git basics references, not everyone is used to working with high activity repo's like Ansibles
08:43:36 <rbergero1> crap!
08:43:56 * jimi|ansible note taking
08:44:14 <jimi|ansible> py3 is progressing!
08:44:14 <gundalow> #topic Python 3
08:44:25 <gundalow> py3 is progressing!
08:44:27 <rbergeron> #info python 3 progressing along nicely
08:44:39 <jimi|ansible> #info integration and unit tests are working on py3
08:44:39 <flaper87> #info py3 has integration tests and unit tests coverage in the core engine. Some tests still missing
08:44:52 <mikedlr> #info serverless architectures on AWS begin to be supported. Lambda there / API gateway added in devel. More can come soon.
08:45:26 <jimi|ansible> #info no official data on users running modules on py3, but bugs are being fixed quickly as they're reported
08:45:31 <rbergeron> #info toshio getting about 5 tests a week
08:45:49 <gundalow> #info toshio getting about 5 bugs a week
08:45:58 <jimi|ansible> o_O
08:46:06 <rbergeron> #info mordred. does not matter.
08:46:09 <rbergeron> :)
08:46:12 <rbergeron> #undo
08:46:14 <hyperized> optional callback feature to report back platform information?
08:46:15 <mordred> :)
08:46:19 * rbergeron needs a chair
08:46:20 <jimi|ansible> #info py2.6 is not going away any time soon
08:46:25 <rbergeron> because my nick changed. i guess.
08:46:32 <jimi|ansible> #chair rbergeron
08:46:32 <zodbot> Current chairs: abadger1999 akasurde dag_ fale flaper87 gregdek gundalow j00bar jborean93 jimi|ansible jlk mikedlr misc mordred nitzmahone pabelanger rbergero1 rbergeron square1 thaumos trishnag ttomecek willthames
08:46:58 <mikedlr> #info integration tests on AWS now work and many run during CI with mattclay's new work
08:47:32 <gundalow> #topic Certified modules
08:47:52 <rbergeron> #info introducing thaomos aka dylan irl!
08:47:58 <gundalow> Working on "Certified modules" aka curated modules
08:48:25 <gundalow> #info Working with partners on this new process and getting them to sign up to this
08:48:42 <rbergeron> #info working on partner / vendor modules with daddy shadowman -- getting vendors to sign up for a process that they'll need to follow so they don't become vaporware
08:48:52 <jhawkesworth_> Train hell, will be on site in about 5 minutes
08:48:59 <gundalow> jhawkesworth_: ack
08:49:00 <rbergeron> #info sla, X # of maintainers required, unit tests, integration tests, etc.
08:49:24 <rbergeron> jhawkesworth_: awesome, we are on the 2nd floor of the hotel when you get here (not in the giant ballroom that you'll also see outside)
08:49:44 <jimi|ansible> yep just follow the signs, we're kind of the last meeting room on the 2nd floor
08:49:47 <rbergeron> warren is dutifully holding a sign in the lobby; plz praise his awesomeness for doing that :D
08:49:58 <rbergeron> (also yay see you soon)
08:50:12 <jhawkesworth_> Will do. Thanks
08:50:45 * misc connect
08:50:54 <abadger1999> #info once the initial work with modules is worked out, will try to expand it to other plugins/roles etc (this is far future)
08:51:16 <rbergeron> #info ppl are expecting us to be grown-ups, vendors want to know how to get their modules "certified" ; hopefully this will be generalize-a-bull
08:51:19 <jimi|ansible> #info working on a generalized process for this
08:51:38 <jimi|ansible> #info ansible is the shizz
08:51:55 <rbergeron> #info we have a ton of modules; thaumos thinks we can't test them all; mordred and rbergeron disagree but it's a detail to get to later :DDDDDDDD
08:52:09 * jimi|ansible agrees with thaumos
08:52:12 <hyperized> I already regret not being there
08:52:32 <jlk> We just need more cloud, then we can test them all.
08:52:34 <jimi|ansible> hyperized: there's always next year :) (or this year, if you want to fly to SF)
08:52:45 <thaumos> @rbergeron :wink
08:52:51 <abadger1999> #info this is acknowlegment that Ansible is partially a platform for people to write and support their modules on.  Need to make it easier for people/organizations to get involved that way.
08:53:00 <jimi|ansible> jlk: i wish we could just rub more cloud on the problem to make it go away
08:53:03 <abadger1999> #topic Questions?
08:53:12 <square1> i wish i knew about the contributors summit before i booked ansiblefest london
08:53:15 <rbergeron> what was the question?
08:53:16 <square1> i would have come for both days
08:53:19 <hyperized> square1: +1
08:53:20 <gundalow> #info All new network modules in 2.4 (core or from community or partner) have to include tests
08:53:43 <hyperized> square1: literally booked the nonrefundable flight 1 hour before I found out there was a 2nd day
08:53:46 <tima> is there a process being discussed for how a vendor contributes to and certifies a community contributed modules for one of their products/projects?
08:53:48 <jimi|ansible> square1: i'll make sure our marketing team hears that, so we advertise it more upfront
08:54:02 <square1> jimi|ansible: perfect, thanks
08:54:19 <willthames> the audio from people who aren't greg is very bad
08:54:23 <rbergeron> tima: is that your question or is that you repeating a question
08:54:32 <tima> mine.
08:54:37 <willthames> inaudible mumbles
08:54:53 <misc> I can hear abadger, not much robyn
08:54:56 <willthames> yes it really helps
08:54:56 <misc> yes, it help
08:54:57 <jborean93> yep
08:55:00 <willthames> monty is loud and clear
08:55:14 <flaper87> willthames: mordred is loud
08:55:16 <flaper87> :P
08:55:18 <jeblair> loud at least :)
08:55:22 <flaper87> hahahaha
08:55:22 <jeblair> flaper87: ^5
08:55:30 <rbergeron> misc: i was just calling out that ... people coulnd't hear so i didn't move to say that into the mic :)
08:55:37 <rbergeron> i am mostly trying to type and pay attention here :D
08:55:44 <willthames> thanks rbergeron :)
08:55:54 <gundalow> #action abadger1999 to review documentation on docs for swapping between py2/py3
08:56:07 <willthames> +1 to py3
08:56:13 <mordred> flaper87: are there any times I'm not loud?
08:56:16 <hyperized> doh I had joined in screen share only mode .. more coffee
08:56:33 <willthames> also good to have more about required_if, required_one_of, etc.
08:56:34 <rbergeron> mordred: when i'm telling you to shut up because it's my turn to talk, sometimes you are less loud then :D
08:56:58 <jlk> Future proofing sounds great, but how about past proofing?
08:57:04 <rbergeron> #info willthames thinks more info about required)if, require_of_of, etc.
08:57:07 <jlk> all the bugs I encounter come from the past...
08:57:09 <misc> multiple timeline proofing
08:57:14 <rbergeron> #info except with ... bettter testing of my typing
08:57:14 <gundalow> Any other questions?
08:57:19 <jimi|ansible> worst timeline proofing
08:57:58 <misc> (I mean, in the land of Doctor Who, you have to speak of timeline proofing)
08:58:33 <rbergeron> #info Tima has question on certified modules: how to handle "certified modules" from the community
08:58:34 <abadger1999> #info has there been discussion of vendors who want to maintain modules but a module already exists that has been contributed by a community contributor.
08:59:07 <jlk> raise your hand if you've enjoyed a synchronize bug.
08:59:09 <jlk> o/
08:59:17 <jimi|ansible> ;_;
08:59:28 <rbergeron> #info tima was just outed as the synchronize module guy. :D IN THE CORNER FOLKS :)
08:59:30 <abadger1999> #info gregdek saying that it will be case by case basis.
08:59:33 <jimi|ansible> lol
08:59:49 <hyperized> open source is open source, don't make a vendor controled project like Java please
09:00:03 <jlk> "Don't pull a left-pad"
09:00:06 <jborean93> what about bug fixes for "certified" modules/what if a vendor is slack
09:00:22 <hyperized> if a vendor wants certification they need to contribute CI?
09:00:23 <jimi|ansible> hyperized: it's not about that, it's about vendors that want to fix bugs in their modules being able to do so more easily
09:00:49 <hyperized> have them add additional an additional CI check before accepting a PR?
09:00:51 <jimi|ansible> in the cases where the module was not written by them
09:00:55 * rbergeron nods
09:01:08 <misc> well, more easily than community might not be the best way to express it :)
09:01:30 <jimi|ansible> well, the vendor is part of the community :)
09:01:35 <misc> true
09:01:37 <thaumos> ^^^^^
09:01:39 <thaumos> they are
09:01:41 <jimi|ansible> so no more easy nor hard than any other part of the community
09:01:47 <rbergeron> also, there will be cases where they are modules for open sourcde projects where there are possible multiple vendors and we may just want to work with that upstream community
09:01:53 * rbergeron looks at openstack for example
09:02:30 <rbergeron> #info people making vague references and inaudible sarcasm relating to third-party CI in the room
09:02:37 <abadger1999> gregdek says many different scenarios: "community author doesn't have time to continue so everyone is happy with the vendor taking over maintenance", "community author is actively maintaining, talk with vendor about working with the community member to see what resources they can bring to *help* the community maintainer"
09:02:41 <misc> my biggest fear is what happen if 1) vendor have shitty code 2) vendor decide to silently change priority but we do not notice :/
09:03:05 <jlk> "inaudible sarcasm" is my progrock jam band.
09:03:06 <hyperized> or the vendor still stears a new feature away if it threatens their business model
09:03:11 <hyperized> *steers
09:03:12 <jimi|ansible> rbergeron using notes to subtweet conversations :)
09:03:35 <rbergeron> misc: I think that's part of the "make it as generic as possible" -- i think that includes the deprecation / unpleasant maintainer process
09:03:36 <willthames> hey greg
09:03:51 <misc> hyperized: nah, that never happen :p
09:03:54 <rbergeron> which probably needs to be fleshed out
09:04:28 <gundalow> #action gundalow to pull his finger out and finish https://github.com/gundalow/ansible/blob/docs-argspec/docs/docsite/rst/dev_guide/developing_modules_general.rst#main-and-ansiblemodule-argument-spec
09:04:33 <hyperized> ok, I guess all it takes is vigilance
09:04:35 <rbergeron> #info gundalow working on update to contributor docs (yay) (i think probably a proposal and things)
09:04:42 <rbergeron> oh there oh dear that's a long link
09:05:26 <misc> hyperized: vigilence, and I guss process to report, decide what happen, etc
09:05:33 <jimi|ansible> i have always been in favor of forcing CI tests for modules that are at least core supported, but i believe i'm somewhat in the minority on that
09:05:47 <hyperized> CI can be light weight (aka: no swear words in the code)
09:05:57 <pabelanger> if it is not tested, it is broken :)
09:05:58 <misc> +1 for more CI
09:06:09 <willthames> we already have light weight CI for everything
09:06:20 <hyperized> it requires that you determine the 'red lines'
09:06:21 <misc> we test syntax :)
09:06:24 <tima> hyperized: what jimi|ansible said -- this about their resources being able to do stuff more easily. If they want to quickly release new features or bug fixes and they have to wait for a community contributor to get around to looking at and approving their PR... their going to start getting frustrated.
09:06:35 <willthames> well, that's very light weight misc :)
09:06:43 <rbergeron> #info mordred explaining the story from other open source projects about vendors and CI and testing and crazy hardware + drivers
09:07:02 <rbergeron> #info sometimes difficiult for companies until they learn from a bizdev perspective
09:07:12 <hyperized> tima: it supports eachother .. if something doesnt build / work why would the maintainer look at it, other than to support the contributor?
09:07:33 <jimi|ansible> requiring CI is easy to say too, but how do we do CI on a lot of 3rd party services if they don't want to give us accounts to test things?
09:07:48 <hyperized> maybe that should be the commitment of said vendor?
09:07:58 <gundalow> We have a session on testing later on today: https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-testing
09:08:04 <hyperized> ok
09:08:09 <hyperized> but testing != ci
09:08:12 <rbergeron> I think where it gets very fuzzy for *us* is when there are mulitiple vendors for the same set of modules in a community
09:08:18 <gundalow> hyperized: +1000000000000000000
09:08:23 <jimi|ansible> hyperized: again easy to say, but if the module came from the community at large and not the vendor, it's hard to sometimes convince that vendor to let us test things cheaply
09:08:26 <thaumos> @jimi|ansible that's part of my point
09:08:39 <thaumos> if we don't have access, how do we get them to filter it back to us
09:08:40 <pabelanger> have a process to setup the CI system for 3rd party also helps greatly. A standard doc for people to run and report public results back to central server
09:08:46 <jimi|ansible> and yeah i say CI in place of testing a lot
09:09:15 <jimi|ansible> because CI is just automated running of the tests
09:09:41 <hyperized> its about acceptence .. tests (in the technical shape) is just one checkbox
09:10:00 <gundalow> Will be moving onto the next topic shortly
09:10:00 <willthames> what about minor PRs to modules without existing tests
09:10:18 <hyperized> willthames: nightmare, but thats where the maintainers can step in
09:10:21 <tima> hyperized: not sure i'm following your point. thinking we are on slightly different pages.
09:10:30 <hyperized> that's fine, this might not be the right time for this :)
09:10:32 <jlk> for things where we need login rights, perhaps a more robust API mocker could be used
09:10:36 <jlk> and the quality of the tests depends on the quality of the mocker.
09:10:36 <gundalow> #info Contributor Involvement
09:10:41 <gundalow> #topic Contributor Involvement
09:11:02 <rbergeron> #link https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-contributor-involvement
09:11:28 <rbergeron> #info (inaudiblenoise as jmckerr walks in and gregdek expects donuts)
09:11:40 <tima> hyperized: the vendors are most concerned about getting support for the latest version of software/services into our releases quickly.
09:12:07 <rbergeron> #info question: how's thing's goin for y'all? (says gregdek)
09:12:16 <gundalow> QUESTION: How are we doing? How are things specifically for you, what are the pain points
09:12:19 <willthames> gregdek: biggest one for me is people leaving the project because we haven't merged their PRs
09:12:23 <abadger1999> gregdek is asking contributors here (in room, on irc, etc) how are we doing?  Are there pain points you need to get addressed?
09:12:25 <hyperized> issues + PR list seems _huge_
09:12:30 <willthames> loads of old PRs that are now just legacy
09:12:37 <hyperized> feels like my issues might not be imporant enough
09:12:43 <abadger1999> Mention that PRs need feedback
09:12:45 <willthames> but really useful to have in future
09:12:49 <hyperized> (not saying they are, but it sends a bad signal)
09:12:58 <gundalow> ANSWERS: Merge my PRs
09:13:07 <abadger1999> Mention that PRs can stack up (contribute but not being merged)
09:13:14 <rbergeron> #info tomas just submitted his first PR; hasn't gotten any feedback.
09:13:19 <gundalow> ANSWER: someone raised a PR and didn't get any feedback about what to do next
09:13:33 <jimi|ansible> #info jlk needs more direction on how to do bot commands / labelling
09:13:40 <rbergeron> #info jlk indicates labels / process / etc. for new folks (esp on modules) could be way more clear. Some of that is moved into the docs for the bot itself
09:14:09 <rbergeron> flaper87: how's YOUR new module going?
09:14:20 <hyperized> our folks here use issue + PR count as a quality indicator for OSS projects
09:14:30 <hyperized> and for Ansible it looks bad :P
09:14:39 <willthames> that's fairly ridiculous hyperized
09:14:43 <gundalow> ANSWER: Not clear how to approve PRs. What do people do: Shipits, GitHub reviews
09:14:59 <willthames> really at best PRs that are waiting on maintainers rather than waiting on contributor might be a metric
09:15:01 <jimi|ansible> hyperized: i agree, the better metric is how long it takes to get things merged
09:15:10 <rbergeron> willthames: yup.
09:15:11 <jlk> wow, that seems... naive .
09:15:15 <willthames> if a PR needs_revision, what can we do
09:15:26 <jimi|ansible> any large project is going to have a ton of open PRs/issues
09:15:37 <gundalow> ANSWER Bot added labels, though it wasn't clear what to do next
09:15:38 <abadger1999> Mention that documentation for how to contribute is not obvious.
09:15:42 <jimi|ansible> go look at kubernetes for instance :)
09:15:48 <rbergeron> yeah. it's time to fix / time to change / time to merge
09:15:55 <tima> which PR # is being discussed?
09:16:10 <gundalow> tima: Process in general
09:16:12 <jimi|ansible> we get 10-20 new issues/PRs per day on average, and usually we close about that many
09:16:12 <tima> Does someone have a URL to it?
09:16:25 <rbergeron> tima: it's from ttomecek -- i will look
09:16:26 <abadger1999> Mention: Need to have a doc about the workflow for PRs.
09:16:47 <jlk> The bot needs to be friendly
09:16:55 <jimi|ansible> tima: yeah need to ask tomas(z?)
09:17:07 <hyperized> maybe have the bot link back to a document that outlines the usual workflow?
09:17:12 <misc> I also think we have people who are new to opensource and those that aren't (and kinda know what happen)
09:17:17 <hyperized> that clears up both the bot behavior and the process
09:17:19 <gundalow> ANSWER Bot needs to be more friendly, clearer what the next steops are
09:17:33 <misc> and since we want to bring more vendor, lots of people might be new to FLOSS
09:17:36 <abadger1999> #info resmo is saying that maintainer of module has less power in the new workflow (because the bot needs more than just the maintainer to approve PRs)
09:17:44 <jimi|ansible> #info make the bot more friendly, and make sure it's always posting links to bot documentation
09:17:49 <jimi|ansible> ^ jtanner
09:18:20 <jimi|ansible> for those who don't know, jtanner (or jctanner) maintains the bot, and there is a github repo for it
09:18:33 <jlk> and we all love him for it
09:18:40 <gundalow> #info a number of processes have gone from explicit to implicit
09:18:42 <jimi|ansible> https://github.com/ansible/ansibullbot
09:18:52 <abadger1999> jimi|ansible: We should probably take action items to ping people... Currently ~5AM east coast.
09:19:05 <jimi|ansible> abadger1999: right, i wasn't sure if he was up, but looks like not
09:19:29 <rbergeron> ttomecek: I am guessing this was a PR to ansible-container
09:19:30 <jimi|ansible> #todo jctanner - make the bot more friendly, and make sure it's always posting links to bot documentation
09:19:33 <hyperized> encourage the use of thumbs up instead of +1'ing :D?
09:19:34 <rbergeron> and not to ansible/ansible?
09:19:59 <rbergeron> question: do we have consistent botting across all the ansible repos?
09:20:14 <rbergeron> or does ansible-container not have the same PR / commenting process
09:20:17 <jimi|ansible> hyperized: i think a lot of people nowadays have gotten used to the thumbs up system in github
09:20:24 <jimi|ansible> i don't see too many people leaving +1 comments anymore
09:20:30 <hyperized> fair enough
09:20:49 <gundalow> #action gregdek and gundalow to loop jtanner into the discussions around contributor docs and process docs so that the bot can be updated
09:20:54 <jimi|ansible> i'm sure it still happens, but thanks for github finally building that into the issue/PR system :)
09:20:56 <gundalow> jimi|ansible: #action
09:21:10 <jimi|ansible> #action jctanner - make the bot more friendly, and make sure it's always posting links to bot documentation
09:21:18 <jimi|ansible> yep, forgetting my bot commands
09:22:05 <jlk> rbergeron: we do not. And in fact, I'm hoping to hijack ansible-container as an early user of BonnyCI for this, which will be a different workflow than the bot.
09:22:05 <hyperized> maintaining maintainers is hard
09:22:39 <rbergeron> #info gregdek wishes for more of a way to have a structure for special interest groups
09:22:45 <jimi|ansible> hyperized: especially when you have like 1000 of them :)
09:22:48 <abadger1999> greg saying that we are at the point where we need to figure out how to create ansible special interest groups.
09:22:50 <rbergeron> hey, what's the difference between and SIG and like, an official ansible project :D
09:22:55 <hyperized> jimi|ansible: do they go missing a lot?
09:23:29 <jimi|ansible> hyperized: well, a lot of modules have individual maintainers outside of the core team, plus the general # of contribs to core itself
09:23:41 <misc> rbergeron: a official project would produce some code, I guess
09:23:45 <misc> like isolated code
09:23:46 <jimi|ansible> over the life of the project, we've averaged about 1.5 new contributers per day to the project
09:23:52 <hyperized> is Gitlab at any point considered, they are further ahead with tooling?
09:23:57 <misc> (atleast, that's how I would understand)
09:23:58 <gundalow> #action gregdek and nitzmahone to look at how to better use the new GitHub permissions. For example ping @ansible-bsd group
09:24:09 <rbergeron> misc: well, I think the idea greg is referring to is sort of ... more of an intersection between "group of people who care about X" which... users and the maintainers?
09:24:20 <abadger1999> So that things like BSD knowledgable contributors can get together and share knowledge and together test and submit PRs and get the PRs merged.
09:24:25 <jimi|ansible> hyperized: we have not considered moving to them
09:24:35 <hyperized> maybe something to at least consider?
09:24:37 <misc> rbergeron: yeah
09:24:52 <rbergeron> i mean there's lots of ways to consider how to do it -- i think ways that encourage not-just-module-writers to participate is useful.
09:24:57 <misc> but I think SIG would be useful, I may have missed the discussion details
09:25:00 <jimi|ansible> hyperized: maybe? i think it would cause a lot of work for an unclear benefit
09:25:01 <abadger1999> hyperized: We have thought about moving to pagure or gitlab, etc... and have decided against it in the past.
09:25:07 <rbergeron> #info gregdek types into etherpad things he could type here
09:25:13 <jimi|ansible> lol
09:25:27 <misc> hyperized: we use gitlab.com at work, and it kinda do not scale that well :/
09:25:38 <rbergeron> #info    Nested groups and read-only collaborators in Github might be super useful to help with the "BSD" problem (spread out modules that aren't well namespaced but need a group of collaborators to help fix)
09:25:45 <rbergeron> #info robyn cuts and pastes for greg
09:25:49 <hyperized> there's considerations to consider, but it seems like we're just waiting for Github to move
09:26:26 <rbergeron> #info improvements to github continue to be nice. but then it also makes us need to rereview the entirety of everything every single time something changes
09:26:31 <misc> hyperized: we do, and that annoy me on a philosophical level :)
09:26:35 <rbergeron> and then they change the API to v4
09:26:41 <rbergeron> and then we cry. :D
09:26:53 <abadger1999> hyperized: ansibullbot has been our answer to github limitations.
09:26:55 <misc> we always cry, we are in IT
09:26:57 <jimi|ansible> and they still don't document a lot of rate limits, which makes jctanner cry
09:27:18 * rbergeron passes out automated ansible kleenex to everyone
09:27:18 <hyperized> abadger1999: having a fixed slot to reconsider the tooling say anually would be nice
09:27:43 <rbergeron> #idea having a fixed slot / time of year to reconsider / rereview tooling would be nice (from hyperized)
09:27:56 <abadger1999> hyperized: It's mostly that github is adding features and we might be able to do things in a more integrated fashion now.
09:28:03 <jimi|ansible> hyperized: one of the biggest problems any project of size has is momentum - changing things like tooling once a year is not a great idea
09:28:15 <hyperized> it worked for shifting the repo :D
09:28:18 <misc> maybe the bot could ping people when someone say "bsd" or "aix" :)
09:28:28 <willthames> hyperized: that is not an example of something that worked
09:28:33 <willthames> maybe something that we survived
09:28:37 <jlk> Tags, now you have 500 problems.
09:28:41 <rbergeron> #info gregdek types into etherpad: (how do we make sure this is the bat signal and not the "everybody gets pinged all the time" thing)   (https://github.com/blog/2378-nested-teams-add-depth-to-your-team-structure)
09:28:49 <jimi|ansible> jhawkesworth_: yeah, i don't ever want to do that again
09:29:23 <abadger1999> #info discussion about having github alias/group/etc that is a directed quesetion "We need someone with expertise in XXX to look at this issue" rather than "Here's a XXX bug that you might be interested in"
09:29:38 <misc> to answer to greg, the rust community do automatically assign people at random for review, maybe we can do that too
09:29:48 <rbergeron> #link history lesson: https://www.redhat.com/archives/fedora-advisory-board/2006-April/msg00220.html
09:29:49 <misc> ie, rather than ping X persons, we ping 1
09:31:07 <jimi|ansible> wikis are where information goes to die
09:31:16 <hyperized> better to have no documentation to outdated documentation
09:31:22 <misc> http://sarah.thesharps.us/2016/11/17/impact-of-bots-on-github-communities/
09:31:31 <jimi|ansible> #info wiki = where information kills itself
09:31:43 <misc> wait, not the right link
09:31:57 <gundalow> Comment was: I think the Windows Group should use SharePoint
09:32:17 <hyperized> wikis work when information has a deadline
09:32:19 <rbergeron> actually, thatmailing list link is a history lesson from jlk and gregdek
09:32:36 <hyperized> so information only lives for say X months and then has to be reviewed and approved
09:32:57 <jlk> geez, 2006.
09:33:15 <hyperized> what greg says
09:33:16 <jlk> rbergeron: I thikn that's Jeremy Katz, not me.
09:33:20 <rbergeron> jlk: but yet, so relevant in some ways
09:33:50 <rbergeron> ohh, you're right
09:33:58 <jlk> even more valid points
09:34:14 <hyperized> ooh greg is going to satisfy needs
09:34:19 <jborean93> gundalow: don't say the s word
09:34:24 <jimi|ansible> when running cobbler, which was 100th of the size of ansible, the wiki still got wildly out of date and i moved it to documentation which was versioned
09:34:38 <jimi|ansible> which is what ansible does, and it's infinitely better
09:35:05 <jlk> Sounds like what they're needing is less long living documentation, and more short living collaborative editing space
09:35:18 <misc> yeah
09:35:37 <jimi|ansible> yes, which we're using issues/prs for in ansible/community
09:35:47 <hyperized> better docs + versioned history might be enough for the average use .. community tools should be seperated
09:35:55 <jborean93> here is the etherpad
09:35:56 <jborean93> https://public.etherpad-mozilla.org/p/Ansible_Windows_Community_Plan
09:36:09 <rbergeron> #info hey neat, best practices for a SIG
09:37:12 <rbergeron> we could do that AND have cross-repo testing too :)
09:37:20 * rbergeron shuts up and runs away
09:39:05 <abadger1999> #info gregdek proposing that ansible/community be setup as a repo that contains sig information.
09:39:22 <hyperized> documentation / workflow / community have overlap but have different documentaiton needs
09:39:39 <samdoran> #info Model ansible/community after kubernetes/community for a place to create and manage SIGs. Enable Wiki on ansible/community.
09:39:43 <misc> hyperized: yup
09:39:44 <willthames> following, all good
09:39:45 <gundalow> #action gregdek to copy k8's community into ansible/community
09:39:48 <abadger1999> #info gregdek proposing giving out commit on ansible/community to anyone who asks.
09:39:58 <abadger1999> (basically)
09:40:00 <jimi|ansible> if we want to turn the wiki on for community, i'm not opposed to it
09:40:26 <jimi|ansible> #action plagiarize kubernetes for sigs and wikis
09:40:30 <hyperized> heh
09:41:56 <abadger1999> #info gregdek proposing turning on wiki in the ansible/community space.  (Identify owners for wiki spaces who are responsible for cleaning up old pages)
09:42:15 <jimi|ansible> huh, apparently ansible/community already has the wiki turned on
09:43:04 <hyperized> I'm confused, what would this wiki serve.. community meeting reports or actual development documentation (or both?)
09:43:09 <jlk> "multiple people mumbling"
09:43:15 <misc> someone time traveled to turn it on ?
09:43:36 <abadger1999> hyperized: I think different people want different things.... Currently, dag is talking about needing something that helps a SIG coordinate tasks.
09:43:56 <hyperized> ok
09:44:14 <dag> yes, it's for new people to find a working group (or SIG) and see what we are working on
09:44:47 <dag> and for the SIG to collaborate better than: https://public.etherpad-mozilla.org/p/Ansible_Windows_Community_Plan and https://github.com/ansible/community/issues/153#issuecomment-286751848
09:45:07 <jlk> This table has reached it's Jesse limit.
09:45:43 <jimi|ansible> another option which might work, is to use Github Pages instead of the wiki, that way the info would at least be contained within the repo and could be updated via PRs a bit more easily by outside contributors?
09:45:52 <abadger1999> #chair hyperized dag
09:45:52 <zodbot> Current chairs: abadger1999 akasurde dag dag_ fale flaper87 gregdek gundalow hyperized j00bar jborean93 jimi|ansible jlk mikedlr misc mordred nitzmahone pabelanger rbergero1 rbergeron square1 thaumos trishnag ttomecek willthames
09:46:34 <jlk> jimi|ansible: if I could speak for dag for a moment, PRs + reviews + merges + live is a bit longer of a work loop than a simple wiki edit.
09:47:02 <jimi|ansible> true, but if you don't have commit access to the repo can you update the wiki?
09:47:20 <abadger1999> #info greg defining what he thinks a SIG is: lightweight body that allows people to collaborate on common interests together.
09:48:03 <hyperized> 'special' interest group
09:48:30 <dag> jimi|ansible: I don't know if Wiki's is going to be the ultimate experience, but Etherpad and Issues currently is problematic
09:48:57 <rbergeron> oh wait. yeah
09:48:59 <jimi|ansible> yeah issues are getting a bit silly... i had originally been doing a new issue per meeting to avoid that endless updating/strikethrough stuff
09:49:05 <jimi|ansible> not really better
09:49:05 <dag> let's see how this works, and evaluate, it's going to make our work easier
09:49:22 <nitzmahone> Yeah- you end up manually moving stuff between tickets which is also a PITA
09:49:39 <abadger1999> dag: <nod>  Sounds kinda like we need a free trello type thing.
09:49:50 <abadger1999> but could make do with a wiki for now.
09:50:04 <jimi|ansible> yeah since we moved away from using trello at all internally
09:50:42 <jimi|ansible> as is, i get confused with the "lightbulb" term and my hue demo...
09:50:52 <jimi|ansible> +1 to survey, it's been a while since we've done one
09:51:30 <hyperized> make it recurring
09:51:43 <hyperized> that way you can tell progress :)
09:51:57 <tima> jimi|ansible true though to my knowledge the Ansible training program started using "lightbulb" first.
09:51:58 <jimi|ansible> we used to do them somewhat periodically, like twice a year back in the day
09:52:04 <jlk> as a "elder" contributor, my experience of how to become a contributor is likely worthless given all the process change since I started. Instead of a survey, we need to do a "shoulder surf" of somebody new trying to become a contributor for the first time.
09:52:08 <hyperized> so action thing?
09:52:14 <jlk> Shoulder surf but do not help/guide at all.
09:52:28 <tima> The "official" lightbulb is here: https://github.com/ansible/lightbulb
09:52:40 <hyperized> easyfix is degenerating, it can be a big problem to a reporter
09:53:00 <j00bar> Django has a #lowhangingfruit tag for issues and a shortcut filter for it.
09:53:07 <j00bar> It works pretty well.
09:53:22 <hyperized> tags ok, but watch phrasing
09:53:36 <jimi|ansible> the problem i always see with these, is that the experienced devs end up just fixing them because they are easy fixes
09:53:46 <tima> The next major topic we are starting to take on is Extending Ansible. That will cover modules and a bit of plugin development primarily and eventually roles to start.
09:54:19 <jimi|ansible> tima: cool, i know i got an internal presentation on that shared with me
09:54:22 <jborean93> usually the people who ask that, need to go through the contributing to Ansible part which can be a slow process
09:54:28 <jimi|ansible> since i was planning on doing more talks on that vein
09:54:33 <jlk> jimi|ansible: is that a bad thing, that things get fixed?
09:54:35 <gundalow> #action write up onboard for each SIG
09:54:44 <jlk> like, we don't have to leave broken things around just for somebody new to pick up
09:54:52 <tima> Always open to expanding that as long as its consistent with the philosophy.
09:54:57 <jimi|ansible> jlk: well that point of those i thought was to get starter devs working on something that's easy to fix to get experience
09:55:05 <jimi|ansible> and instead experienced devs fix them
09:55:17 <jlk> jimi|ansible: they are useful for that, but we don't necessarily have to ignore them to let newbies pick it up
09:55:31 <jlk> experienced devs often need some quick wins, either due to time concerns or burnout.
09:55:39 <jimi|ansible> right
09:55:45 <abadger1999> jimi|ansible: That (devs fixing) can be a social problem that we change, though.
09:55:46 <gundalow> jlk: +1
09:55:51 <misc> qualify all documentation as easyfix also cheapen the work of documentation writer :/
09:55:51 <abadger1999> jimi|ansible: if we want to do easyfix.
09:55:58 <jimi|ansible> but even something i think might be easy to fix can still end up sucking 4-8 hours of my time away
09:56:26 <samdoran> Glad I'm not the only one that happens to. :)
09:56:36 <abadger1999> jimi|ansible: Just tell devs, write up what you think someone should do but don't actually fix it.
09:56:42 <hyperized> maybe: non-technical vs program sort of tags instead?
09:56:48 <j00bar> easyfix should be a change that is obvious what to do, simple to test, and impacts no more than 5 lines of code.
09:56:53 <jimi|ansible> not at all, which is why i generally focus on things labeled "bug_report" only, because those are generally the hard things to tackle on github
09:57:00 <j00bar> code and/or docs.
09:57:23 <jimi|ansible> j00bar: i've had more 1 line "fixes" break things in subtle ways than 100 line changes
09:57:52 <j00bar> jimi|ansible: that's what test suites are for.
09:58:33 <jlk> sure, easyfix and friends are just a quick assumptive labeling.
09:58:35 <jlk> it's not going to always be true
09:58:51 <hyperized> lunch for me, see you guys later
09:59:00 <jlk> and that's okay, for somebody to pull it off the stack, look at it a bit, discover it's way harder, and document their findings and put it back into the stack
09:59:15 <gundalow> ......................
09:59:16 <gundalow> ......................
09:59:16 <gundalow> ......................
09:59:16 <gundalow> ......................
09:59:16 <gundalow> ......................
09:59:18 <gundalow> ......................
09:59:19 <zodbot> gundalow: You've given me 5 invalid commands within the last 60 seconds; I'm now ignoring you for 10 minutes.
09:59:49 <jborean93> gundalow: looks like you are taking a 10 minute break
10:03:16 <misc> nope, that's the meetbot part
10:03:29 <misc> the regular bot (linmora) match on .
10:03:31 <misc> .fasinfo
10:03:32 <zodbot> misc: (fasinfo <username>) -- Return information on a Fedora Account System username.
10:03:36 <misc> .fasinfo misc
10:03:37 <zodbot> misc: User: misc, Name: None, email: misc@zarb.org, Creation: 2010-02-02, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
10:03:40 <zodbot> misc: Approved Groups: proventesters cla_fedora cla_done fedorabugs cla_fpca gitfedorareview +packager fi-apprentice
10:11:18 <willthames> jborean93: do you fancy doing 5-10 minutes on Contributor Summit tomorrow night? I might mention it either way
10:11:44 <jborean93> willthames: sure, I'll try and put something together
10:15:27 * rbergeron 
10:15:30 <rbergeron> woops
10:16:42 <rbergeron> #link https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-backlog
10:19:02 <bcoca> grows like a kid on a milk farm
10:21:05 <abadger1999> greg: "Expectations are killing OSS developers"
10:21:38 <gundalow> #chair
10:21:38 <zodbot> Current chairs: abadger1999 akasurde dag dag_ fale flaper87 gregdek gundalow hyperized j00bar jborean93 jimi|ansible jlk mikedlr misc mordred nitzmahone pabelanger rbergero1 rbergeron square1 thaumos trishnag ttomecek willthames
10:21:39 <abadger1999> greg: whole bunch of people in the last few months saying that they don't have time for all the responsibilities I've taken on.  This is making me burn out.
10:22:05 <gundalow> #action gundalow to speak to jtanner to see if we can get the stats he collects public
10:22:31 <abadger1999> greg: Things that we (paid to work on it) hold ourselves accountable to may not be the same things that community should hold itself to.
10:22:47 <jimi|ansible> i remember when we averaged 10/day...
10:22:53 <bcoca> or 2
10:23:30 <abadger1999> greg: setting expectations appropriately for both the job that we're doing and the job that the contributors are doing.
10:24:08 <abadger1999> jimi saying: raw number count not as important as average time to close.
10:24:23 <bcoca> not all PRs are equal
10:24:25 <gundalow> #info the average time for a PR to work through the process is an important stat
10:24:30 <dag> I have jtanner's module stats URL
10:26:03 <bcoca> gregdek: that is how we approach triage, PRs higher priority (bug PRs > feature)
10:26:49 <willthames> can't hear whoever is talking now
10:26:56 <abadger1999> greg: saying that PRs are higher priority
10:27:11 <abadger1999> jimi and gundalow saying that we have 9 external committers, 36 total committers.
10:27:18 * jlk whispers that we just need more people the bot considers "approvers", so that the bot can put the appropriate review/label on the PR that allows the CI system to merge the thing.
10:27:21 <bcoca> not including BOT
10:27:27 <gundalow> #chair bcoca
10:27:27 <zodbot> Current chairs: abadger1999 akasurde bcoca dag dag_ fale flaper87 gregdek gundalow hyperized j00bar jborean93 jimi|ansible jlk mikedlr misc mordred nitzmahone pabelanger rbergero1 rbergeron square1 thaumos trishnag ttomecek willthames
10:27:52 <abadger1999> greg: should we ad more committers?
10:28:12 <abadger1999> jlk: Saying could bot do this?
10:28:37 <gundalow> Answer: Bot already does this for modules
10:28:41 <abadger1999> #ingfo bot currently allows for contributors to a file to approve PRs for that file.
10:28:49 <abadger1999> #info bot currently allows for contributors to a file to approve PRs for that file.
10:29:03 <bcoca> gregdek: we are already in process of that, in 2.4 adding docs to other pugins, including metdata
10:29:03 <jimi|ansible> assuming the commit is directly to a plugin/module_utils, but a lot of times code external to those files is touched as well
10:29:05 <gundalow> #info current Bot maintainers https://github.com/ansible/ansibullbot/blob/master/MAINTAINERS.txt
10:29:07 <jimi|ansible> say to the Base class
10:29:09 <abadger1999> maintainers file that lists permissions per file or per directory that the bot bases off of.
10:29:11 <jimi|ansible> or utils
10:29:20 <willthames> and also assuming the module is community, not committer
10:29:31 <abadger1999> Currently contains information for modules.  Could work for other file paths as well.
10:29:46 <willthames> #info I think there are too many committer modules (particularly in aws, as an example I'm most familiar with)
10:29:55 <gundalow> #info We are currently working on adding docs and metadata to other plugins
10:30:09 <gundalow> willthames: How do you mean?
10:30:39 <willthames> modules that can't have community shipits and need committer shipits
10:30:42 <tima> rbergeron: from like an hour ago -- the PR ttomerek was talking about: https://github.com/ansible/ansible/pull/25734
10:31:59 <willthames> gundalow - supported_by in metadata
10:32:03 <abadger1999> #info modules that have a specific committer then do not fall under group maintainance.
10:32:30 <willthames> abadger1999: a specific *maintainer* isn't it?
10:32:38 <abadger1999> willthames: Ah yeah.
10:32:40 <abadger1999> #undo
10:32:40 <zodbot> Removing item from minutes: INFO by abadger1999 at 10:32:03 : modules that have a specific committer then do not fall under group maintainance.
10:32:49 <abadger1999> #info modules that have a specific maintainer then do not fall under group maintainance.
10:32:49 <willthames> but your point otherwise stands abadger1999 :)
10:33:48 <jborean93> there's also a lot of bugs/prs that are out of date and need some pruning
10:34:39 <misc> but can github delegate triage ?
10:34:45 <jimi|ansible> jborean93: we have internally started a backlog meeting where we go through old issues like that
10:34:52 <ryansb> with the bot we can delegate a lot
10:34:54 <abadger1999> #info greg talking about potential to create a triage sig
10:34:55 <jimi|ansible> doing that more in public as a SIG would be nice
10:35:03 <ryansb> using commands like needs_info etc
10:35:10 <misc> true
10:35:14 <jimi|ansible> that was originally my intention with the community IRC meeting
10:35:26 <jimi|ansible> but then we started doing proposals, etc. and it's become its own thing
10:35:36 <ryansb> but yeah, GH does make it tricky by not having good permissions
10:36:33 <jlk> #info Getting reproducers from issues is one of the biggest problems.
10:36:40 <jlk> Perhaps that can be a specific effort by community folks, to trawl the issues that do not have reproducers, and create them?
10:37:15 <ryansb> That would be really helpful
10:38:17 <willthames> who is speaking now?
10:38:25 <willthames> before the current person :)
10:38:31 <nitzmahone> mikedlr
10:38:36 <abadger1999> jlk: I was thinking that a good thing to try would be to get a PR for a test that reproduces associated with a bug. Then merge that PR once it goes green in CI.
10:39:00 <jlk> abadger1999: yeah, that's a nice test driven development thing
10:39:09 <rbergeron> #idea Have a metrics SIG if there are people who care about metrics and want to use math to start figuring ot what the sources of problems are rather than bikeshedding? :)
10:39:11 <jimi|ansible> i would love that
10:39:19 <jimi|ansible> ^ what abadger1999 said
10:39:45 * rbergeron notes there are varying opinions on metrics (vanity vs. using it as source of noticing whether things are going to hell in a handbasket)
10:39:48 <jimi|ansible> only problem is that the PR for the test would not be contained in the PR to fix the issue, and you'd have to rebase the test PR?
10:39:48 <rbergeron> etc.
10:39:53 <rbergeron> and uh, make them public
10:40:02 <willthames> louder please
10:40:09 <jlk> good is having a written reproducer. Better is having a git repo that has a reproducer written into it. Best is having an ANsible PR with the failing test as the reproducer.
10:40:31 <jimi|ansible> jlk++
10:40:32 <jlk> jimi|ansible: well, depends on your CI
10:40:35 <jlk> jimi|ansible: some CIs will test the content of the PR merged to the target tip
10:40:38 <abadger1999> jimi|ansible: yes, we can't escape having to rebase older PRs.  If the issue is fixed quickly then we wouldn't have to.
10:40:47 <jlk> abadger1999: you can escape that, with a better CI :D
10:41:09 <rbergeron> automation fixing the automation project
10:41:11 <rbergeron> hmmmmm
10:41:14 <abadger1999> jimi|ansible: The problem is not having an association between bug and test PR that makes the merge automatic.
10:41:15 <rbergeron> :D
10:41:19 <jimi|ansible> jlk: right we do have the tests rebase against devel (or whatever branch) currently on shippable, however if they test and fix are in different PRs i'm not sure if that's easy to deal with?
10:41:22 <abadger1999> But perhaps it could be a bot command?
10:41:26 <willthames> #info shipit_on_tests_passing might be a useful bot flag :)
10:41:35 <abadger1999> ansible_test_pr: #1111
10:41:37 <jimi|ansible> i know zuul kind of does that, but won't it fail the early test?
10:41:38 <jlk> well
10:41:58 <jlk> it'll fail at submission, as intended
10:42:15 <jimi|ansible> like, PR X comes in with the test and then PR Y comes in with the fix, zuul would test them combined and i think it'd work?
10:42:28 <jimi|ansible> but if there's a long lag time between X and Y, i'm not sure how zuul deals with that?
10:42:31 <abadger1999> jimi|ansible: The fix-pr should not fail.  Then the next time the test PR is run through ci it should succeed.
10:42:32 <jlk> if a fix goes in, the fix can mention the PR, which will either cause a human or a bit to drop a "retest" like comment in the original PR
10:42:35 <jlk> upon re-test, if the fix has merged, it should pass
10:42:52 <abadger1999> jimi|ansible: the problem is that we wouldn't be testing the fix-pr with the test-pr before merging.
10:43:00 <jlk> jimi|ansible: zuul handles it well if you drop a "Depends-On" somewhere on the failing test
10:43:16 <jlk> but that means you have to know that the "fix" PR has been created so you have a target for 'Depends-On'
10:43:23 <jlk> alternatively
10:43:25 <jimi|ansible> abadger1999: right that's what i'm saying
10:43:28 <jborean93> it would help to identify ones that the issuer opened and aren't looking at anymore and can be closed
10:43:30 <jlk> now this is really fun
10:43:40 <jimi|ansible> the fix pr won't fail, but if we merge the test PR in first it'll make all other PRs fail until the fix is in
10:43:48 <jlk> n/m, strike that.
10:43:59 <jlk> ah ah
10:44:07 <jlk> so
10:44:10 <jlk> zuul handles that
10:44:10 <rbergeron> lol
10:44:33 <jlk> in the FIX pr, you say "Depends-On: test-PR"
10:44:44 <jlk> zuul tests them together, MERGES them in succession
10:44:48 <pabelanger> Question, does ansible have a bug / PR maintainer? Somebody who actively tries to move a long stalled reviews?
10:44:58 <jimi|ansible> ok cool, so it just depends on a comment in the commit
10:44:59 <jlk> does not break subsequent things.
10:45:18 <rbergeron> jlk: we do have some time on the afternoon schedule for zuul chat in the general testing section, though it's mostly "limit monty to 10 minutes of update, no squirrels" but ... we could explain more. (plus we have the deeper zuul thing after)
10:45:23 <jimi|ansible> so no more issues, open PRs with reproducers only :)
10:45:30 <jlk> jimi|ansible: right, this is fresh code as far as github is concerned, it's driven by commit messages in the commits in the PR. Could be extended to also read comments on the PR
10:45:55 <jlk> yeah, there's a lot to educate on zuul.
10:46:05 <jimi|ansible> nah no need to do that, just read the PR comment i mean
10:46:19 <abadger1999> #info Discussion about how the bot can discourage a submitter because the bot will autodetect problems and make the contributer do things.  But then if the maintainer (core or community) isn't actually looking at the PRs then the submitter did all this work for no apparent end ability to merge.
10:46:36 <jimi|ansible> #info zuul will fix everything
10:46:38 <jimi|ansible> :)
10:47:00 <resmo> probably pinging all maintainers on a regular basis e.g. every 4 months? just too see if they are sill willing?
10:47:20 <resmo> or got under the bus?
10:47:23 <jimi|ansible> resmo: that's noise, i already have a huge queue of messages from github on things i've been assigned/mentioned on
10:47:26 <jlk> jimi|ansible: well.... in gerrit land it keys off of the commit message, not any comments in the gerrit change. We're keeping that as a compatibility on github side.
10:47:49 <jimi|ansible> jlk: right that's all i'd expect
10:47:53 <jlk> gotcha.
10:47:57 <willthames> ping all seemingly inactive maintainers?
10:48:01 <resmo> jimi|ansible: not pinging you, but the module maintainers
10:48:03 <jlk> re current topic
10:48:05 <resmo> :)
10:48:14 <jimi|ansible> comments on the issue/PR i'd leave in the domain of the bot
10:48:33 <jlk> I know that Fedora had done many things to "detect" inactive maintainers. Did that actually help in any measurable way?
10:48:37 <jimi|ansible> resmo: ahh, yeah still could be noise but that's up to the module maintainers
10:48:54 <jlk> jimi|ansible: zuul _does_ respond to PR comments, such as "retest", which just re-enqueues the change into the pipeline.
10:48:57 <jimi|ansible> maybe something module maintainers could opt-in to?
10:49:07 <jimi|ansible> jlk: ahh well neat :)
10:49:19 <rbergeron> do we care about responses to issues vs. prs?
10:49:36 <resmo> jimi|ansible: if a maintainer thinks that is noise it should not be a maintainer
10:49:41 <jimi|ansible> rbergeron: probably not? comments on issues don't generally trigger anything other than labeling for the bot
10:49:50 * rbergeron nods
10:49:55 <jimi|ansible> i don't think any CI/CD mechanism needs to care about comments on issues
10:50:03 <misc> resmo: well, the problem is also that there isn't much filtering github side
10:50:18 <misc> (at least on the web interface)
10:50:24 <rbergeron> oh, i wasn't saying it had to be related to CI / CD, wqas just saying "does a crapton of issues == inactive maintainer"
10:50:54 <bcoca> again, inactive/active i think is irrelevant
10:50:55 <jimi|ansible> rbergeron: maybe? depends on if any of those comments were from the maintainer themselves?
10:50:58 <jlk> This all feels like trying to apply some machine learning to github data.
10:51:02 <bcoca> having 'enough' is more important
10:51:16 <rbergeron> jlk: yeah
10:51:43 <jlk> inactive maintainer detection is targeting a symptom, not the problem
10:51:51 <rbergeron> jimi|ansible: comments or issues? (do you mean # of comments in issues?)
10:51:55 <jlk> problem being a selection of PRs/Issues are getting ignored/backed up
10:52:25 <abadger1999> #info greg assembling a list of questions, stats to gather, and some ideas of policy in the etherpad https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-backlog#lineNumber=67
10:52:26 <jimi|ansible> rbergeron: issues or prs? just looking for a large # of comments doesn't really indicate anything to me
10:52:47 <jtanner> Jlk admitting the problem is first step
10:53:02 <rbergeron> https://docs.ansible.com/ansible/honeybadger_deployment_module.html
10:53:59 <jimi|ansible> honey badger don't care
10:54:41 <nitzmahone> jimi|ansible++
10:55:18 <rbergeron> jtanner!
10:56:43 <abadger1999> greg: communication is key.
10:57:37 <willthames> #idea add labels to all module PRs
10:57:49 <jimi|ansible> #action stats - more, and more public
10:58:06 <gundalow> ALL: Any other action ideas in here?
10:58:06 <willthames> to help find other PRs in the same area but also count PRs/issues by module
10:58:09 <abadger1999> jlk: Does the point you make about the real problem need to be called out to the room?  Does it change anything on greg's list in the etherpad?
10:58:13 <jimi|ansible> #action stats - see in-room discussion in etherpad for specific stats
10:58:49 <jlk> abadger1999: I think it's fine.
10:58:55 <abadger1999> k
11:00:00 <jtanner> willthames: what label(s)? there's already module + topic + subtopic labels
11:00:15 <willthames> jtanner I guess specific module
11:00:34 <jtanner> the only reason i haven't done that already is that it means 1200+ new labels
11:00:38 <jimi|ansible> willthames: we do already have stats per module, that's pretty easy (though it is broken at the moment apparently...)
11:00:59 <willthames> jtanner: I did have that thought, I wasn't sure *how* problematic that would be
11:01:02 <bcoca> https://ansible.sivel.net/byfile.html
11:01:06 <willthames> labelling through the UI might be harder
11:01:14 <willthames> but the bot would cope
11:01:19 <misc> lunch !
11:01:31 <jimi|ansible> it's easy to figure out from the file path for the bot/stats reports, don't need a label for that when it's a module
11:01:50 <jimi|ansible> but it's why i started doing the component labels for the core engine bits, to figure out where the hotspots are
11:02:08 <willthames> jimi|ansible: for me, as a maintainer, it's the ability to say this is a new PR, what other PRs are open that might clash/conflict/be better
11:02:36 <jimi|ansible> ahh yeah, that'd make things easier to spot via the github ui itself
11:02:50 <willthames> at the moment I'm doing long reviews, suggesting big improvements, and only later realising - oh I should have noticed this huge clash earlier
11:03:03 <gundalow> ALL
11:03:07 <gundalow> ONE HOUR BREAK
11:03:18 <ryansb> willthames: yeah, that happens to me a fair amount
11:03:23 <willthames> especially if contributor actually makes that change, could be wasted work
11:03:43 <willthames> off for a run now, enjoy lunch, I'll be a little over an hour
11:14:52 <bcoca> willthames: i use the linke above (sivel's page) mostly to find other PRs against same files, does not scale well when more than 2-3 files are involved
11:17:32 <jlk> Github's graphql and search API should work well for that
11:17:47 <bcoca> hmm, 2 'easyfix' bugs over a year old ..i think that is either mislabled or really unappealing
11:18:09 <bcoca> jlk: not really, not for 'pending PRs in conflict with this one'
11:18:32 <jlk> oh, there's a missing bit of GraphQL covering that
11:18:35 <bcoca> ^ sivel's page uses the api to get that list
11:18:44 <jlk> I filed an issue on it already. With the Rest API you can get files in each PR commit
11:18:53 <jlk> it's missing in GraphQL, hopefully it'll be added soon
11:19:05 <jlk> then you can get it all in one API call instead of an iteration of REST calls
11:19:09 <bcoca> tat would be awesome
12:03:29 <rbergeron> #link https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-testing
12:03:36 <newtMcKerr> nitzmahone…CAB ping?
12:05:00 <rbergeron> can everyone hear gundalow okay?
12:05:05 <ryansb> Yup
12:05:06 <jborean93> yep
12:05:30 <abadger1999> #info gundalow giving out information about testing.
12:06:03 <rbergeron> awesome, thanks :D
12:07:02 <abadger1999> #info 2.3 => devel, large percentage increase in coverage for both integration and unit tests.  But we started from a low number of tests to begin with so still a large amount to do
12:07:13 <abadger1999> #info problems to overcome: test instability
12:07:41 <abadger1999> #info tests that talk to external resources that go away (like installing packages from external package resource)
12:08:43 <ryansb> can't hear the questions, so if you could repeat them before answering that'd help lots
12:08:48 <hyperized> +1
12:09:01 <abadger1999> Questoin was: How do we support the macos hosts?
12:09:09 <ryansb> thanks abadger1999
12:09:34 <bcoca> we drive to starbucks and hijack the machine of the guy writing 'the next big play'
12:09:50 <hyperized> hackintohs
12:10:00 <hyperized> did someone already dockerize macos :D?
12:10:00 <jborean93> the chance that Windows instances not coming up has dramatically decreased in the past few months which is great
12:10:02 <abadger1999> #info macos hosts for shippable are taken care of by spinning up a virtual mac box via a hosting service.
12:10:49 <jimi|ansible> ^ same with windows
12:11:16 <abadger1999> #info want to select some tests as good examples in various categories (standar, network, aws, windows)
12:11:21 <jimi|ansible> until MS allows Windows to run inside a container not running on Windows as a host
12:11:42 <abadger1999> #info zuul working on reference implementation tests for themselves as well.
12:12:23 <hyperized> maybe a commitment that can be asked from MS?
12:12:47 <jborean93> I don't think MS will support a Windows container on a non-windows host
12:12:50 <jborean93> anytime soon
12:12:55 <abadger1999> #action mordred and gundalow/mattclay to talk about reference implementations for tests that will help with both zuul and ansible
12:13:08 <hyperized> jborean93: I'd like to assume things too D:
12:13:14 <bcoca> containers dont really work when you need to change kernels
12:13:19 <bcoca> its always going to be VMs
12:14:23 <jborean93> reference tests should show things like check/diff mode, parsing variables and not be too complex
12:14:29 <jborean93> reference modules*
12:14:33 <abadger1999> #info for reference implementations, also looking for good modules (esp. windows)
12:20:34 <abadger1999> #action gundalow to look for both simple and complex examples for reference integration tests.
12:22:05 <jlk> Would it be wrong to just write "fixed by zuul" in all these problems?  :D
12:22:17 <abadger1999> #info stale_ci label: added to tickets if ci hasn't been run in ~7 days.  meant to tell committers to trigger a new ci run before merging.
12:23:16 <abadger1999> jlk: We wanted to avoid getting out the whip and saying "code faster!" to ya'll ;-)
12:23:27 <jlk> hahah. No worries.
12:23:52 <hyperized> Gitlab allows you to restart CI :D
12:24:03 * hyperized goes back into the corner
12:24:21 <abadger1999> #chair mattclay
12:24:21 <zodbot> Current chairs: abadger1999 akasurde bcoca dag dag_ fale flaper87 gregdek gundalow hyperized j00bar jborean93 jimi|ansible jlk mattclay mikedlr misc mordred nitzmahone pabelanger rbergero1 rbergeron square1 thaumos trishnag ttomecek willthames
12:24:32 <willthames> gundalow: ask the bot to auto rebase to trigger ci :)
12:24:32 <jlk> it's not a hard problem, it's just a "agree on a method" problem.
12:24:55 <bcoca> its not that simple as shippable api is involved, not just github
12:24:56 <jlk> #info if picking a word to feed the bot, please pick "recheck" -- Monty
12:25:00 <abadger1999> #info mattclay says that it is a known feature request to add a bot command to rerun ci but it hasn't been written yet.
12:26:16 <abadger1999> #info note: features need to be available in shippable's API in order to implement.
12:26:35 <hyperized> there's PRs open for changelog .. should those not exist then?
12:26:40 <hyperized> or used exclusively?
12:27:38 <abadger1999> #info remember, 2.3 needs python-2.4 module-side compat.
12:27:51 <willthames> use the mics people!
12:28:02 <jimi|ansible> my bad
12:28:21 <jimi|ansible> jlk and i were talking about if you can block direct commits to a branch via branch protection
12:30:05 <abadger1999> hyperized: At this moment, it would be core team will probably just update the changelog directly.  Others will add changelog entries via PRs.
12:30:49 <hyperized> ok
12:31:05 <abadger1999> hyperized: We've found that github's merge button uses a different merge strategy which makes it hard to manage changelogs without conflicts (merging from the git cli is possible due to setting a merge strategy for the changelog that makes that work without as many conflicts)
12:31:30 <abadger1999> So PRs for changelog can be a bit painful.
12:31:52 <jlk> The merge button has 3 strategies now
12:32:11 <abadger1999> hyperized: if you see PRs that are just for changelog entries, we probably should prioritize getting those merged (as they need rebase so frequently)
12:32:16 <jlk> none of which are totally great :)
12:33:06 <abadger1999> jlk: <nod>  We have "CHANGELOG.md merge=union
12:33:17 <jlk> abadger1999: what other projects do is have a compiled changelog using a directory full of snippits, so that they don't conflict.
12:33:33 <abadger1999> in our .gitattributes.  but none of the github UI utilizes that.
12:33:52 <hyperized> is there a feature request for that?
12:33:55 <abadger1999> jlk: <nod> Yeah --we've looked at reno and not enough of hte right peole got on board.
12:33:58 <hyperized> the least that can be done is asking
12:34:20 <abadger1999> upstream pyhthon also has a tool (not quite released) that I'd like to look at.
12:34:53 <abadger1999> hyperized: I don't believe we've opened one.  Would be good to have that asked for.
12:35:09 <hyperized> it seems like a good feature overall
12:35:48 <bcoca> we do have a git setting on changelog to be 'less fussy' about conflicts, but it is not absolute
12:36:00 <bcoca> and has created dupe entries in past
12:36:21 <abadger1999> bcoca: <nod>  I mentioned that above.  (And that it works for git cli but not for github's merge button)
12:36:32 <bcoca> ah, did not know that!
12:36:36 <hyperized> pain: shippable and then not actually being shipped (happened on two issues I follow)
12:36:57 <hyperized> pain: not being informed when it'll be included in a release (bot maybe?)
12:37:16 <abadger1999> #info question about how to run tests: see a tox file and it doesn't work.  See a make test and it doesn't work.  etc.
12:37:53 <misc> there is a PR for that
12:37:58 <hyperized> I hope someone can voice my concern, i'm not in the room :)
12:38:14 <abadger1999> <nod>
12:38:18 <misc> https://github.com/ansible/ansible/pull/25915
12:38:35 <misc> (fred is sitting next to yanis, who just speak)
12:38:37 <misc> spoke
12:39:07 <hyperized> about current speaker: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/CONTRIBUTING.md :)
12:39:17 <hyperized> example of it working pretty well
12:39:29 <jborean93> would be good to know the process around dealing with external dependencies or binary files. How do we get them easily accessible in our integration tests
12:39:30 <jtanner> what was just said in the room? i didnt understand what he was talking about
12:40:24 <abadger1999> #info jeblair mentions that openshift writes a shell script to do all the setup for making a test environment.
12:40:45 <misc> can  people speak louder ?
12:40:51 <misc> (or more in the mic)
12:40:53 <abadger1999> #info gundalow says that ansible-test has a --requiremenets cli that can help with that for pypi packages.
12:41:07 <misc> (I can hear if I focus, but people are speaking next to me in french :/ )
12:41:08 <rbergeron> #link https://docs.openstack.org/infra/bindep/
12:41:23 <jtanner> ansible-test is the solution to all of this
12:41:32 <gundalow> misc: fixed
12:41:34 <rbergeron> https://docs.openstack.org/infra/bindep/readme.html#examples
12:41:40 <misc> gundalow: thanks :)
12:41:47 <abadger1999> #info monty mentions that there's a further file that they have (bindep) that helps install non-pypi things.
12:41:55 <rbergeron> #link https://docs.openstack.org/infra/bindep/readme.html#examples
12:42:05 * misc is now reaching for his nerf to shoot on coders in the openspace
12:42:06 <abadger1999> #action monty to ping gundalow with information about bindep.
12:42:40 <abadger1999> hyperized: What's the first pain you mentioned (shippable and then not actually[...])
12:43:05 <hyperized> tagged, but not actually included
12:43:16 <jtanner> how is the bot supposed to know?
12:43:22 <jimi|ansible> side note, gregdek and I are writing a Fiddler on the Roof alternative entitled "If I were a gentoo man"
12:43:47 <hyperized> feels like I gotta chase after bugs sometimes, that shouldnt be neccesary
12:44:06 <abadger1999> hyperized: do you mean tagged "backport"?  Or "not knowing if it was cherrypicked or not"?  Or "not knowing what release a cherry-pick will actually show up in?"
12:44:34 <jtanner> define "chase after"
12:44:43 <hyperized> no @ backport, not knowing what happens if something is tagged ship_it
12:45:08 <hyperized> jtanner: yeah looking for an example
12:45:18 <jtanner> shipit is a pathway to devel merge ... it doesn't have scope beyond that
12:45:48 <abadger1999> hyperized: if it gets tagged shipit, then it should get merged to devel eventually... which means next major release.  Says nothing about previous major reeleass (so right now, would get put into 2.4 but doesn't get into 2.3)
12:45:55 <hyperized> well then that's probably the best voiced part, as a issue reporter I am mostly just interested in when I can get it to work again on my platform
12:46:15 <jtanner> even if the bot does the cherry picks, it doesn't get to decide when stable branches get cut to new releases
12:46:16 <gundalow> #action gundalow to add "when cherry picking to detail what release will be released in. Also must do cherry pick -x
12:46:53 <hyperized> yeah skip that question
12:46:53 <abadger1999> hyperized: cpould you explain that one?
12:46:56 <hyperized> its pretty much covered
12:47:00 <willthames> TIL about cherry-pick -x
12:47:06 <hyperized> thanks
12:47:13 <rbergeron> willthames: :D
12:47:15 <bcoca> ^ i use git cp (which is alias to -x)
12:47:39 <jtanner> we need -x for tracking back to devel commit
12:47:57 <jtanner> re: testing ... we need a VM based testing solution
12:48:08 <jtanner> beause our scope in containers is limited
12:48:14 <bcoca> it is in our internal 'git workflow doc'
12:48:28 <bcoca> make tests-nonet
12:48:30 <bcoca> make tests
12:49:27 <mattclay> The plan is to remove most of the make targets for testing, except for tests which aren't supported by ansible-test yet.
12:49:43 <abadger1999> #info want to start pushing people to ansible-test as the Makefile is going to stop working as we add more things to makefile
12:50:18 <mattclay> I'm not referring to `make test`, but the test/integration/Makefile targets.
12:50:44 <bcoca> ok, those i dont care
12:50:46 <gundalow> #action gundalow to speak to Mattclay about deleting the old old win_groups.yml
12:50:57 <abadger1999> #info mattclay says we can leave the toplevel make test but will get rid of the test/integration/Makefile targets.
12:51:40 <mattclay> #info If anyone has trouble with ansible-test (usage, argcomplete not working, etc.) please ask me on IRC
12:51:46 <gundalow> mattclay: Anything you'd like to give an update on yet
12:52:39 <hyperized> more PRs :D
12:53:11 <mattclay> gundalow: I think you've covered the highlights pretty well.
12:53:21 <gundalow> #info Code Coverage https://codecov.io/gh/ansible/ansible/
12:54:00 <misc> wondered if we could give some rating to PR based on metrics
12:54:09 <misc> like "increase code coverage" +1
12:54:13 <misc> add a test +2
12:54:25 <hyperized> contains references to cats +3
12:54:27 <misc> and then sort them for review based on the score
12:54:52 <ryansb> huh, interesting. So get bumped up the review queue by having more tests
12:55:01 <misc> yeah
12:55:02 <hyperized> helps triage :)
12:55:05 <mattclay> misc: Eventually, yes. It's more difficult than it might seem since we the tests we run are dependent on the contents of the PR.
12:57:16 <misc> mattclay: codecov is cool, thanks for doing the integration with the service :)
12:58:24 <hyperized> coverage is one thing .. is static analysis another?
12:58:31 <hyperized> is there even such a thing for Python?
12:58:45 <misc> there is bandit, but that's focus on security
12:58:51 <misc> there is pyflake/pylint and others
12:58:54 <hyperized> it can solve legit bugs
12:59:05 <hyperized> or at least hilight them
12:59:07 <abadger1999> hyperized: there is.  mattclay are we just using a subset of pylint or are we doing a subset of pylint and a subset of pyflakes?
12:59:50 <pabelanger> https://github.com/ansible/ansible/pull/25962 <- fixes one issue for running tox the first time on a local system
12:59:55 <pabelanger> who ever was asking for that
13:00:12 <hyperized> ok I have a meeting now, won't probably be able to join back but I'll be on-site tomorrow :) hoping to see some of you guys there
13:00:41 <spredzy> pabelanger: https://github.com/ansible/ansible/pull/25915
13:01:09 <abadger1999> #info mikedlr pointing out that the module coverage won't account for things like code which could raise multiple exceptions and we're only testing that it catches one of those.
13:01:31 <abadger1999> #info testing working group, gundalow, mattclay are points of contact.
13:01:36 <abadger1999> #undo
13:01:36 <zodbot> Removing item from minutes: INFO by abadger1999 at 13:01:31 : testing working group, gundalow, mattclay are points of contact.
13:01:42 <abadger1999> #info testing working group, gundalow, mattclay are points of contact for more testing questions
13:01:44 <pabelanger> spredzy: cool
13:02:52 <square1> hyperized: see you tomorrow :)
13:03:01 <mikedlr> PR that I mentioned which aims to centralise the exception handling code so that the coverage problem is reduced: https://github.com/ansible/ansible/pull/25780
13:03:27 <abadger1999> #topic 10 minute overview of zuul
13:03:52 <abadger1999> #info zuul is a "gating engine" from openstack.  Used for CI.
13:04:07 <bcoca> mikedlr:  mostly against centralized errors as they give very little useful data to users, it is much better when they are handled locally and developer gives context with a useful error message
13:04:14 <abadger1999> #info jobs in zuul v3 are written in ansible.
13:04:53 <bcoca> centralized errors normally just give 'api lib error' which does not tell a user what the module was attempting nor with what info and if user can possible remediate or if it is out of their hands
13:05:01 <abadger1999> bcoca: His Pr is good.  It centralizes the code; not hte catching.
13:05:01 <mikedlr> bcoca: this is handled in our case in two ways:  the call to the cental exception takes a string which says what you were doing
13:05:19 <gundalow> #info Zuul v3 is alive
13:05:30 <mikedlr> and b) the AWS exceptions are pretty good about explaining what went wrong so we simply pass through that string.
13:06:08 <bcoca> boto is generally good, but not across the board, soo basically you are just making another version of jail_json?
13:06:25 <mikedlr> so you get "deleting RDS instance: Exception AWS call timed out" or something similar pluss a prpper traceback.
13:06:49 <ryansb> jail_json: the BSD way to isolate failures
13:06:52 <mikedlr> bcoca: yes - fail_json_aws("this is what I'm doing", exception)
13:06:59 <bcoca> well, timeouts are the easy part (500s etc) the issue is more when incompatible/incorrect data is supplied
13:07:04 <rbergeron> #link https://softwarefactory-project.io/sf/welcome.html
13:07:19 <mikedlr> actually aws_module.fail_json_aws(...)
13:07:42 <rbergeron> #info software factory stuff, plus ...
13:07:43 <gundalow> *ALL* Can people that are attending (especially those on IRC) please "sign in" at the end of https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-agenda
13:07:44 <rbergeron> #link https://github.com/softwarefactory-project/software-factory
13:07:46 <bcoca> will look at code , but it seems redundant
13:08:10 <gundalow> Thanks in advance
13:08:51 <misc> might be useful to also paste on the bjn chat ?
13:09:05 <abadger1999> #info zuul does multi-repo dependencies (commit to one repo can trigger CI runs for other repos)
13:09:16 <ryansb> misc: done
13:10:54 <abadger1999> #info to rollout for ansible:
13:11:08 <abadger1999> #info Enable a github app "openstack Zuul"
13:11:34 <abadger1999> #info Run zuul's test suite on PRs to Ansible.
13:11:48 <abadger1999> #info run shade's test suite on PRs to Ansible Openstack Modules
13:12:20 <abadger1999> #info Then spin up "Ansible Zuul" github App which runs ansible tests when commits are made.
13:15:06 <jlk> "I don't know how to stop sharing" -- Robyn.
13:15:24 <misc> i was wondering
13:16:03 <bcoca> i know how to stop, i just dont want to!
13:19:09 <pabelanger> mattclay: raise your hand please !
13:20:24 <rbergeron> #topic INTRODUCTIONS
13:22:03 <rbergeron> everyone is introducing themselves.
13:22:08 <rbergeron> not everyone works on openstack.
13:22:27 * jimi|ansible changing business title to "introducing bugs as a service"
13:25:08 <misc> in fact, we have others windows people at RH
13:26:12 <jborean93> there are dozens of us, DOZENS!
13:27:28 <jimi|ansible> lol
13:31:42 <jtanner> zuul track: "NOTE: NEED SOME CORE TEAM FOLKS HERE. DESPERATELY. Save jlk from being sad at weird hacky things. Please!"
13:33:52 <P-NuT> Hi all. I'm heading to AnsibleFest London tomorrow.
13:33:59 <P-NuT> Anyone else going?
13:34:50 <misc> lots of people already are going, yes
13:35:38 <nitzmahone> jborean93 (and anyone else interested in Windows): bluejeans link posted in etherpad
13:35:56 <jborean93> nitzmahone, thanks opening it up now
13:37:26 <jtanner> rbergeron: zuul bluejeans hasn't started ... not sure if that's expected
13:40:00 <bcoca> can i get link to active sessions?
13:47:45 <jtanner> bcoca: zuul https://bluejeans.com/2413805790/
13:47:51 <jtanner> others are in main etherpad
13:48:11 <jtanner> https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-agenda
13:48:19 <shertel> Ansible Container: https://bluejeans.com/3008457278/
13:48:19 <shertel> Windows:  https://redhat.bluejeans.com/6841238455/?src=meet_now
13:51:44 <bcoca> thnx shertel
13:53:27 <jimi|ansible> #endmeeting