19:00:17 <gregdek> #startmeeting community
19:00:17 <zodbot> Meeting started Wed May 11 19:00:17 2016 UTC.  The chair is gregdek. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:17 <zodbot> The meeting name has been set to 'community'
19:00:23 * gundalow waves
19:00:25 <bcoca> http://xon.sh/
19:00:29 <gregdek> :)
19:00:30 <bcoca> mt
19:01:00 <rbergeron> hi!
19:01:17 <MichaelBaydoun> bcoca: but thanks for that, looks interesting
19:01:23 <gregdek> wat
19:01:51 <rbergeron> wat wat?
19:01:53 <gregdek> oh, neat.
19:01:55 <gregdek> xonsh
19:01:59 <gregdek> ANYWAY
19:02:12 <gregdek> Agenda as always: https://waffle.io/ansible/community
19:02:44 <rbergeron> yet-another-shell
19:03:18 <bcoca> ^ was pasting to friend in 'things i won't add support to ansible for'
19:03:28 <bcoca> ^ iwould take 'fish' aways if i could
19:03:40 <gregdek> Welp, as last week's meeting was a good "made some progress week" for me, this week... won't be. Sigh.
19:03:58 <gundalow> gregdek: quick meeting then :)
19:04:08 <bcoca> admiting lack of progress is progress!
19:04:14 <gregdek> Yeah, maybe followed immediately by doing things.
19:04:15 <gundalow> What's #81 for?
19:04:17 <gregdek> Anyway.
19:04:40 <gregdek> #topic community/81
19:04:47 <gregdek> It's a great tool that sivel set up. Check it:
19:04:49 <gregdek> https://ansible.sivel.net/pr/byfile.html
19:04:59 <rbergeron> 81 is linking sivel's tool in the packaging guidelines. :)
19:04:59 <gregdek> We *really* should be encouraging its use.
19:05:12 <gundalow> It's a great tool. What's it got to do with packaging though?
19:05:39 <gundalow> I wonder if it should be referended in CONTRIBUTING/I've found a bug (maybe it's fixed already) type docs
19:05:47 <sivel> maybe packaging guidelines is the wrong word
19:05:50 <sivel> s
19:05:53 <gregdek> Right. That's part of the problem. Where does it live?
19:05:57 <gundalow> hey sivel :)
19:06:02 <rbergeron> err
19:06:05 <rbergeron> packaging?
19:06:08 <rbergeron> did isay packaging?
19:06:10 <gundalow> hey rbergeron
19:06:14 <gregdek> It's this great... thing, that is sorta sitting off to the side and useful for many things and not known.
19:06:20 <gregdek> How do we make it better known?
19:06:33 <gregdek> And i keep going "well, maybe doesn't belong there, hmm lemme THINK ABOUT IT SOME MORE FOREVER"
19:06:34 <rbergeron> oh, that's what it says in the issue... gregdek, is this really "packaging"?
19:06:44 <rbergeron> or just contributing?
19:06:53 <gregdek> It's a great place for contributors to see All Their Things!
19:07:13 <gregdek> "Hey, I'm a Foo Maintainer. What things are open against Foo right now?"
19:07:20 <rbergeron> i guess the question is... do we even have packaging guidelines?
19:07:27 <gregdek> Module guidelines is what that should say.
19:07:43 <gregdek> And now it does.
19:07:47 <gundalow> I think it would be useful to link from
19:07:53 <gregdek> BUT: I'm not even sure that's where it goes!
19:07:55 <gundalow> 1) http://docs.ansible.com/ansible/community.html#i-d-like-to-report-a-bug - See if there is a PR for the module
19:08:12 <rbergeron> okay. thank you. (sorry, i just glaze over "packaging guidelines" at this point in my life post-fedora, so used to seeing that set of words together)
19:08:26 <rbergeron> contributor and maintainer tools?
19:08:29 <gundalow> 2) http://docs.ansible.com/ansible/community.html#contributing-code-features-or-bugfixes Before you start coding see if their is a similar fix/update in flight
19:08:45 <rbergeron> we have talked about having a place to link to other things as well (ansible-lint, etc)
19:08:57 <rbergeron> useful tools for maintainers, contributors, and users?
19:08:59 <gundalow> 3) #5 what rbergeron just said
19:09:16 <rbergeron> it is useful and maybe there is a better place for it as part of ... the maintainership life cycle
19:09:30 <rbergeron> but just having more word about it out there would probably be useful in figuring out ultimately how it fits in :)
19:09:33 <gregdek> We don't really have a Maintainer FAQ, do we?
19:09:49 <gregdek> We just have Module Guidelines.
19:09:52 <rbergeron> not really.
19:10:01 <gregdek> But not really a "this is what being a Maintainer entails".
19:10:09 <rbergeron> i mean, having something at least setting out "what you should expect when you are expecting... to be a maintainer"
19:10:10 <gregdek> So MAYBE...
19:10:21 <gregdek> ...that's what this PR actually is.
19:10:22 <rbergeron> seems like it might be helpful or at least set expectations
19:10:25 <gregdek> And has been all along.
19:10:32 <gregdek> And sivel's tool goes in it.
19:10:38 <gregdek> And links to the module guidelines.
19:11:15 <rbergeron> and might be a useful thing to link to as well in (a) new module template, (b) maybe the first ping back from ansibot after someone submits a pr, (c) "remember this, it's helpful" when the module is actually merged
19:11:27 <rbergeron> gregdek: this seems like a good idea.
19:11:30 <gregdek> Yes Yes Yes
19:11:31 <gregdek> Yes.
19:11:50 <gregdek> OK, gonna rename this issue and copypasta all of this into it.
19:12:42 <rbergeron> gregdek: seems like someone making a rough cut or outline and putting it in an issue and then mailing the -devel list to see "what else do maintainers think would be useful to know about" could be a thing.
19:12:53 <rbergeron> like, i'm sure they have all sorts of stuff.
19:13:11 <rbergeron> like knowing that amazon modules have their own additional guidelines, stuff like that
19:13:18 <gregdek> Yep.
19:13:23 <rbergeron> is something that is not just... super immediately obvious
19:13:46 <rbergeron> okay! you, me, or... /me looks for anyone jumping up and down all around
19:14:06 <gundalow> Does ansibot know if a module is AWS, can we get it to add a link to the AWS guidelines?
19:14:06 <rbergeron> this kind of thing i am able to be decently okay at :)
19:14:35 <gregdek> rbergeron: you want it, I will assign it :)
19:14:36 <rbergeron> we could tell it that "if it's in xyz directory, add additional text" probably
19:14:45 <rbergeron> gregdek: do it, like a boss
19:14:49 <rbergeron> literally and figuratively
19:14:53 <MichaelBaydoun> Can the aws guidelines extend the general guidelines ... like we do for module documentation?
19:15:14 <gregdek> gundalow: we could conceivably make modifications to the bot, but all of this has to be figured out
19:15:22 <MichaelBaydoun> so all specific guidelines also contain the general guidelines
19:15:25 <gregdek> Current guidelines are quite ad hoc
19:15:54 <rbergeron> https://github.com/ansible/ansible-modules-extras/blob/devel/cloud/amazon/GUIDELINES.md
19:16:07 <gregdek> rbergeron: you are proud owner of extras/81 :)
19:16:28 <rbergeron> i think the bigger problem is tht people don't always know about the guidelines to begin with (until maybe after they are informed by ansibot since that at least is linked to begin with, the general module guidelines)
19:16:34 <gregdek> Yes.
19:17:00 <rbergeron> and so should exist somewhere probably relatively close to the general contributor docs that are ... in docs
19:17:02 <gregdek> That was actually one of the biggest wins of Ansibullbot: letting people know about the guidelines with every single PR.
19:17:04 <rbergeron> not just buried in github somewhere
19:17:25 <gregdek> Well, it's your problem now :)
19:17:33 <gregdek> WOO NOT IT
19:17:37 <gregdek> (but yes)
19:17:43 <rbergeron> thanks!
19:17:51 <gregdek> We've needed to reorganize for quite a while.
19:17:56 <rbergeron> gregdek: did you copy the above bits from convo in there?
19:17:59 * rbergeron goes to look
19:18:01 <gregdek> I did.
19:18:33 <rbergeron> indeed. i just added a reminder about the amazon modules as well.
19:18:38 <rbergeron> okay, will go forth on this one :)
19:19:21 <rbergeron> gundalow: thanks for asking what 81 is about :)
19:19:38 <gregdek> w00t!
19:19:40 <gregdek> next:
19:19:43 <gundalow> rbergeron: Thank you for offering to do all the work :)
19:19:50 <gregdek> #topic community/42
19:20:07 <rbergeron> gundalow: making sure contributors have useful things in obvious places so they can be successful is a thing that makes me happy :)
19:20:09 <gregdek> rbergeron: can haz phx meetup?
19:20:24 <gundalow> rbergeron: :D
19:20:26 <rbergeron> gregdek: i just updated this and moved it into the in-progress column (which i guess you can see)
19:20:44 <gregdek> Yep. Looks good. Any more comment needed or just "yup it's movin'"?
19:20:44 <gundalow> NEXT!
19:20:53 <rbergeron> it looks like it will be the week of 6/20, toby (the rhug organizer for phx) is working out exact date with hosts
19:20:58 <rbergeron> who kindly provide food and everything and nice space
19:21:06 <rbergeron> ....on the other side of town, but whatever :)
19:21:08 <gregdek> yay!
19:21:15 <gregdek> Everywhere in PHX is "the other side of town"
19:21:19 <rbergeron> unless it's 2 miles from me ... yes, that, exactly
19:21:51 <gundalow> oooh, Phoenix, AZ
19:21:57 <gundalow> (ignore me)
19:22:10 <gregdek> gundalow: a phan oph phoenix?
19:22:29 <gundalow> never been to AZ
19:22:34 <rbergeron> yes, it's hot and miserable here
19:22:39 <gregdek> It's hot.
19:22:54 <rbergeron> not all of AZ is hot. flagstaff is not. but you have to shovel craptons of snow there instead. :)
19:23:03 <rbergeron> but where i am... ugh. hot!
19:23:07 <rbergeron> anyway: what's next?
19:23:11 <rbergeron> and yes, "it's movin"
19:23:25 <gregdek> As in, "oh look, 60 celsius! I didn't know thermometers went that high."
19:23:36 <gregdek> ANYWAY.
19:23:41 <gundalow> lol
19:23:44 <gregdek> Avoiding my next failure:
19:23:44 <gundalow> NEXT!
19:23:54 <gregdek> #topic community/72
19:24:01 <gregdek> Adoptme report.
19:24:11 <gregdek> Actually, this should be pretty easy, just haven't gotten to it yet.
19:24:21 * rbergeron nods
19:24:21 <gregdek> This will be made much easier with contributor guidelines.
19:24:51 <gregdek> Because then I can just say "here's the list of orphans, want to know how to adopt? Go to $guidelines_that_robyn_is_writing
19:25:01 <gregdek> But in the meantime, we can get a basic report moving quickly.
19:25:05 <gregdek> So that's on the list.
19:25:41 <gregdek> Next:
19:26:25 <rbergeron> s/contributor/maintainer
19:26:31 <gregdek> #topic community/80 -- SLA for shipit
19:26:32 <rbergeron> gregdek: agreed though, yes, totally
19:26:39 <gregdek> (yes, thx rbergeron)
19:26:52 <gregdek> So this led to a lot of good discussion.
19:27:31 <gregdek> And I *think* the answer is "in one of the weekly core meetings, we hit anything that's been in shipit for more than two weeks."
19:27:36 <gregdek> And I think that's good enough.
19:28:03 <gundalow> HIT THEM
19:28:06 * rbergeron nods
19:28:08 * bcoca ducks
19:28:11 <gregdek> whoa!
19:28:15 <gundalow> hello Brian :)
19:28:16 <gregdek> GUNDALOW SMASH
19:28:20 <gundalow> hehe
19:29:12 <gregdek> What came out of the discussion was, if it hasn't been merged after two weeks in shipit, there's probably a reason that defies an easy "merge or revise" decision.
19:29:33 <gregdek> Which makes it an ideal candidate for actual discussion. Thus the proposal.
19:29:44 <rbergeron> yup.
19:30:15 <gregdek> So we *did* make progress on that one. I'll continue to chase until we agree that core meeting is the remedy, and then will close.
19:30:27 <rbergeron> worth noting that lots of folks were very curious about "current metrics for this" -- and I think making sure we are actually reporting on those metrics (and making sure that people understand that there may be a buffer bit of time while we try to catch up)
19:30:50 * resmo waves
19:30:52 <rbergeron> is probably useful to do in some way, maybe / somehow
19:30:54 <gregdek> Hi resmo!
19:30:54 <rbergeron> hey resmo :D
19:32:19 <rbergeron> i also jsut don't want to get totally tied up in figuring out where the metrics are right now as a way to determine what the sla shoudl be -- i think picking a target and going forward is pretty sane.
19:32:25 <gregdek> Yep.
19:32:34 <rbergeron> anyway. so yes, continue chasing :)
19:32:43 <gregdek> ok, moving on:
19:33:22 <gregdek> #topic community/63 -- number of orgs in galaxy
19:33:34 <gregdek> rbergeron: has this been filed in galaxy-issues?
19:35:42 <rbergeron> @gregdek: ooh, i think so. chris and i talked about it. let me double checka nd i'll add the issue link and then close
19:35:47 <gregdek> ok.
19:35:52 <gregdek> Moving on:
19:36:12 <gregdek> #topic community/40 -- Code of Conduct!
19:36:15 <gregdek> Well.
19:36:40 <rbergeron> linked and closed #63 :)
19:36:54 <gregdek> After much back-and-forth, it seems like we're farther ahead than our friends at RH, and we should probably just close this one for now.
19:37:11 <gregdek> We've got something good, and it's live, and that's good enough.
19:37:25 <gregdek> There may be Other Lofty Discussions, but if so, those will be new things.
19:38:59 <gregdek> So I've closed it as "done". w00t!
19:39:00 <rbergeron> gregdek: ????
19:39:18 <rbergeron> i guess i'm lost a bit, but whatever. we have your address and that's a nice enhancement to what we had previously. :)
19:39:30 <gregdek> rbergeron: CoC is an internal tug-of-war, and by simply having a Nice Policy, we're ahead of the game.
19:39:50 <gregdek> So it's time to declare victory and stay low for now. :)
19:40:30 <gregdek> Next:
19:41:51 <rbergeron> ...next... ? :)
19:42:03 <gregdek> #topic community/36 -- issue triage!
19:42:11 <rbergeron> yay
19:42:17 <gregdek> resmo: how goes?
19:42:37 <gregdek> Any luck with the Issue Triage PR?
19:42:50 <resmo> its tricky to get the issue linked to the modules (as you already pointed out)
19:42:59 <resmo> and not reliable
19:43:19 <gregdek> Yes.
19:43:28 <resmo> that is the only issue I am fighting right now
19:43:40 <rbergeron> resmo: would any more explicit wording help? "it must take this format or the bot will yell?"
19:43:40 <resmo> not sure how to solve it
19:43:42 <gregdek> Yep. That's been the biggest one all along. :)
19:43:49 <gregdek> By being brutal.
19:43:52 <jtanner> resmo: because you can't determine the string that represents the module name?
19:44:01 <gregdek> "If you don't explicitly tell us what module this affects, we can't help you."
19:44:08 <resmo> jtanner: exactly
19:44:10 <rbergeron> jtanner: that may be more like it
19:44:32 <resmo> some users just uses AWS foobar, some gitlab_* etc
19:44:47 <rbergeron> resmo: what if they explicity added it in a comment directly after filing the issue? (i mean, that seems like totaly hackery, but...)
19:44:50 <jtanner> resmo: my most recent approach was to just get all words that are known module names, and interactively triage those with multiple matches
19:44:51 <gregdek> And we say "sorry, we don't know what that is."
19:45:01 <gregdek> foo = (match_string.split("COMPONENT NAME\n")[1]).split("\n")[0]
19:45:13 <rbergeron> yeah, there might be some issues that affect multiple modules, which is ... ugh
19:45:16 <jtanner> it's definitely easier if there's a field in the issue which should only have a module name/path
19:45:39 <rbergeron> jtanner: yeah, i think it's just making sure people know to type fullname.py
19:45:39 <gregdek> And if foo doesn't equal something we recognize in MAINTAINERS-CORE or EXTRAS, we flag it with "unknown module" or some such.
19:45:52 <jtanner> rbergeron: i wouldn't expect an extension
19:46:20 <resmo> we should also make it clear in the github template that we need the exact module name or even better the paths/module
19:46:23 <rbergeron> jtanner: maybe. unless we say specifically "blahblah.py" --
19:46:26 <gregdek> resmo: fine with that.
19:46:35 <rbergeron> i think getting paths may be harder, but ... who knows
19:46:39 <jtanner> some people have no idea that the modules are python files
19:46:44 <gregdek> We should be unapologetic about collecting the data we need.
19:46:59 <resmo> rbergeron: yes, this is also my opinion
19:46:59 <gregdek> And if they can't provide it, we can perhaps flag it for some periodic review, but that will take longer.
19:47:15 <gregdek> Always privilege users who give us the most actionable data. Always. It drives behaviors.
19:47:35 <jtanner> i agree, but it won't matter if the behavior is not enforced
19:47:47 <rbergeron> it might be a case where having a mini-team of folks who are willing to help triage (ie: could add in a full name in an additional comment)
19:48:11 <jtanner> "unknown_module" label
19:48:20 <jtanner> man effort required
19:48:22 <gregdek> Worst case: x% of issues don't get triaged automatically. Right now the value for x is 100%. :)
19:48:25 <jtanner> manual*
19:48:46 <rbergeron> ...could be a thing. like, anything marked "needs_triage" by the bot that can't figure out the name... like, that's a fairly easy thing that i could do... but still tell people "the fastest way to get things routed is to really follow instructions" :)
19:49:12 <bcoca> leave it unlabled, core triage person already looks at all unlabled
19:49:20 <gregdek> Anyway, resmo, does that help?
19:49:26 <jtanner> resmo: another trick might be to scan/search for parameters related to certain modules
19:49:33 <rbergeron> maybe in the documentation for a module ... ohhhh. hmm.
19:49:46 <resmo> gregdek: yes
19:50:04 <jtanner> resmo: https://github.com/jctanner/pr-triage/blob/master/triage_2.py#L286
19:50:08 <gregdek> resmo: jtanner will have a lot of input on this going forward. :)
19:50:18 <rbergeron> like, maybe in the documentation for a module (or above what is automagically imported) we could have a line that says "if you want to report an issue on this module, be sure to use the full name of the module, which is blahblahblah.py" and just ... have that magically get built in?
19:50:31 <rbergeron> since i suspect when modules don't work, documentation is the first place they go
19:50:37 <resmo> jtanner: I see
19:50:44 <rbergeron> and seeing "oh hey, this has a full name" might help solve some of that
19:51:30 <rbergeron> which also isn't an easy fix, but ... /me shrugs, throwing ideas out there
19:51:55 <gregdek> I vote for simple incremental improvement. :)
19:52:23 <resmo> :) it could only get better from this point
19:52:34 <rbergeron> like, in the section where it says "This is an Extras Module
19:52:58 <rbergeron> " or something --
19:53:05 <rbergeron> or maybe we just don't require the .py (or we take either)
19:53:12 <jtanner> i prefer either
19:53:19 <rbergeron> since like.. the list of modules in documentation looks like...
19:53:20 <rbergeron> http://docs.ansible.com/ansible/list_of_monitoring_modules.html
19:53:22 <MichaelBaydoun> or, in each modules documentation, is a create issue link that auto populates the correct full module name
19:53:22 <jtanner> and no path required, but helpful if added
19:53:25 <gregdek> OK, a quick update from gundalow re: travis (since he has to run)?
19:53:28 <rbergeron> it's the name of the module, but doesn't show the .py extension
19:53:34 <rbergeron> gregdek: sure
19:53:44 <gregdek> (sorry to cut discussion short, we will revisit often)
19:54:00 <gregdek> #topic community/47 -- travis performance
19:54:04 <gregdek> gundalow! go!
19:54:13 <gundalow> #topic community/47
19:54:24 <gundalow> So, I finally got an email back from the people at Travis. They don't have public queue/pending statistics, but they do have that internally (I've followed up and asked for a dump). The ability to have selective jobs (don't test everything on say a docs change) doesn't exist, and isn't on the short/medium plan. It can however be done by our own service using the API https://docs.travis-ci.com/user/triggering-builds. Paying them money gives us a bi
19:54:39 <gundalow> Still hoping well get *something*
19:55:10 <jtanner> one thing to note: now that sivel's http container is merged, the test runs are probably going to be longer on average because they won't fail early on SNI failures
19:55:26 <jtanner> so the queue might get backed up worse than it is now
19:55:43 <gundalow> shaved ~ 100 seconds off the integration tests (per OS distro) by having a number of the dependencies preinstalled see https://github.com/ansible/ansible/pull/15692/files
19:56:11 <gundalow> Havig some strange issues with docker on my laptop, that are stopping me getting clean figures for all the distros
19:57:08 <jtanner> gundalow: interesting ... i thought the tests would just fail if the deps weren't installed
19:57:09 <gundalow> as jtanner stated, we will not net 100seconds, but it will still be a net gain even once you factor in sivel's http container change (which gives us much more stable tests)
19:57:28 <gundalow> jtanner: The dependencies are currently installed by Ansible as part of the test
19:57:30 <jtanner> test_unarchived killed my entire run last night because unzip was missing
19:57:49 <jtanner> maybe destructive vs. non ?
19:57:50 <gundalow> jtanner: That's strange as test_unarchive installs zip
19:58:07 <sivel> fortunately the failing SNI tests were at almost the end of destructive, so it shouldn't be too different
19:58:50 <gundalow> jtanner: what TARGET?
19:58:55 <jtanner> ubuntu1404
19:59:08 <jtanner> oops
19:59:09 <jtanner> no
19:59:29 <jtanner> i might be thinking about local runs on an el7 vagrant box
19:59:38 <jtanner> ignore what i said before
20:00:09 <gundalow> ah, cool
20:00:15 <gundalow> well, I'm glad it wasn't something else
20:00:35 <gundalow> right, Im off
20:00:50 <gundalow> unless anyone has any other pointers
20:01:01 <gundalow> I expect travis performance to be an ongoing task
20:01:05 <gregdek> Yes.
20:01:09 <gregdek> Thanks gundalow :)
20:01:18 <gundalow> laters
20:01:32 <gregdek> OK, we're at our hour. Anyone have anything urgent?
20:01:38 <jtanner> on the topic of test performance, i think we may have a lot to gain from putting more artifacts into sivel's http container
20:01:53 <jtanner> such as git repos with branches and test roles
20:02:31 <jtanner> topic for another day i suppose
20:03:09 <gregdek> It's probably time to have a separate testing working group. :)
20:03:14 <gregdek> Or near time.
20:04:52 <gregdek> #endmeeting