19:16:36 <rbergeron> #startmeeting ansible community working group meeting
19:16:36 <zodbot> Meeting started Wed Mar 23 19:16:36 2016 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:16:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:16:36 <zodbot> The meeting name has been set to 'ansible_community_working_group_meeting'
19:16:42 <rbergeron> #chair gregdek
19:16:42 <zodbot> Current chairs: gregdek rbergeron
19:17:02 <gundalow> Hey :)
19:17:20 <rbergeron> hiya.
19:17:26 * rbergeron is waiting on gregdek to arrive back
19:17:32 <gregdek> sorry about that back now
19:18:00 <gundalow> That's cool. First session of a new meeting will always over run :)
19:18:52 <gregdek> #info agenda as always https://waffle.io/ansible/community
19:19:05 <gregdek> #topic Travis Performance
19:19:12 <gregdek> https://github.com/ansible/community/issues/47
19:19:24 <gregdek> gundalow: anything new here?
19:20:00 <gundalow> On holiday, so not going to have any time till next week
19:20:09 <gregdek> hey ssmoogen :)
19:20:25 <smooge> my apologies.. having netwrok issues
19:20:43 <rbergeron> gundalow: no worries. we can check back next week! :)
19:20:47 <gundalow> though it appears we are running ansible 51times which takes ~ 10 minutes. If we can chop that into two 5 minute runs that sounds like a win
19:21:09 <rbergeron> #info gundalow to check in next week with progress -- on vacation right now :)
19:21:27 <rbergeron> #info note: appears we are running ansible 51times which takes ~10 minutes. If we can chop that into two 5 minute runes that sounds like a win
19:21:34 <gundalow> :)
19:21:42 <rbergeron> okay, next!
19:21:44 <gundalow> </topic>, unless anyone has any questions
19:21:45 * rbergeron thinks gregdek is having leag
19:21:47 <rbergeron> lag
19:21:52 <gregdek> Ditto.
19:22:21 <gundalow> FYI Mosh + Screen + irssi = winful
19:22:55 <rbergeron> #topic Document / implement triage process
19:22:58 <rbergeron> #link https://github.com/ansible/community/issues/36
19:23:05 <rbergeron> Okay, so, progress is:
19:23:16 <rbergeron> I started a bunch of stuff in gliffy over the weekend.
19:23:41 <rbergeron> And now gliffy is offline beacuse ...
19:23:43 <rbergeron> "We are experiencing a system failure. We are working on restoring access to our system.
19:23:47 <rbergeron> For the most current updates, visit our support page. We apologize for the inconvenience."
19:24:00 <rbergeron> Which basically says "we can't restore our stuff. let alone yours"
19:24:01 <rbergeron> lol
19:24:02 <gregdek> greeeeeat
19:24:10 <rbergeron> Anyway: I have the old file on my machine, and gliffy on my local machine.
19:24:18 <rbergeron> I was just doing it in google because hey, i can share!
19:24:31 <rbergeron> anyway:
19:24:35 <rbergeron> i'm gonna give it another day
19:24:37 <rbergeron> and if not
19:24:40 <rbergeron> i'll just ... back to the beginning.
19:24:46 <gundalow> "On working to resolve the issue, an administrator accidentally deleted the production database." *cough*
19:24:51 <rbergeron> but i do have the gliffy file from the previous chart on my machine now.
19:25:06 <rbergeron> or something really close to it, and we have the .png of how it looks in the repo somewhere.
19:25:26 <rbergeron> so i can replicate that without much effort if needed (since it needs fixing, it looks like, depending on how our tweaks to module process go)
19:25:31 <rbergeron> and issues... yeah.
19:25:40 <rbergeron> issues is pretty easy, except for the corner cases :)
19:27:52 <gregdek> ok, will check back next monday
19:28:02 <gregdek> (b/c no meeting friday)
19:28:17 <rbergeron> #topic docs proposals process
19:28:18 <rbergeron> #link https://github.com/ansible/community/issues/23
19:29:37 <rbergeron> #info status: spent a bunch of time tryign to preserve history, but now i'm not going to do that.
19:29:46 <rbergeron> #info going to just copy over things and hopefully not break the universe.
19:30:04 <rbergeron> #info gregdek says JUST DONT GIT PUSH TO ANYPLACE OTHER THAN PROPOSALS
19:30:09 <gregdek> lol
19:30:11 <rbergeron> #action rbergeron to heed gregdek's advice
19:31:47 <gundalow> all though proposals_process_proposal.MD it states "ansible/proposals", should that be ansible/docs/proposals
19:32:16 <rbergeron> gundalow: no, things are moving to ansible/proposals
19:32:27 <rbergeron> and so i need to move existing things in docs/propposals over to ansible/proposals :)
19:32:28 <gundalow> oh, it is moving
19:32:33 <rbergeron> gundalow: exactly
19:32:37 <rbergeron> #topic code of conduct
19:32:40 <gundalow> cool :)
19:32:53 <rbergeron> #link https://github.com/ansible/community/issues/40
19:33:02 <rbergeron> gregdek: updates?
19:33:31 <gregdek> #info gregdek reached out to a couple of community members, waiting on pings back and a potential PR
19:33:47 <gregdek> Should have something by next week
19:34:48 <rbergeron> #topic clarify pr labels and process
19:34:53 <rbergeron> #link https://github.com/ansible/community/issues/45
19:35:29 <rbergeron> so: we know we have existing pictures of this
19:35:42 <rbergeron> i am not sure if all the discussions we just haed in the previous meeting means this stuff is hugely changing.
19:35:46 <rbergeron> gregdek: thoughts?
19:36:07 <gundalow> Would be good to have a page with the status and ensure it's keep upto date
19:36:11 <gregdek> Where is the existing picture again? in committers?
19:36:12 * gregdek looks
19:36:25 <gundalow> though I know this is up in the air, even more so with the previous meeting
19:37:06 <gregdek> https://github.com/ansible/ansible-modules-extras/blob/devel/REVIEWERS.md
19:37:13 <gregdek> This is quite out of date.
19:37:23 <gregdek> We've sort of ditched the idea of an SME, for instance.
19:37:30 <rbergeron> yeah.
19:37:45 <rbergeron> have we ditched the idea of needing worksforme AND passes guidelines?
19:37:55 <gregdek> yeah, it's now two shipits
19:38:06 <rbergeron> that's what i thought.
19:38:26 <rbergeron> #info now two shipits, just around 'it works'
19:38:43 <rbergeron> #info though a needs_revision can be added if it doesn't pass guidelines
19:39:41 <gregdek> Yeah, and "shipit" no longer means "shipit", it means "final review".
19:39:56 <gregdek> Which calls into question, should we change the "shipit" flag to "final review" or something?
19:39:56 <rbergeron> #info shipit doesn't automagically mean it will get shippped, it means "goes to final review by core team"
19:40:07 <gregdek> Since it's discouraging to think "hey i made it" and then "awwww"
19:40:28 <smooge> that is what it should be called: "awwwww"
19:40:35 <bcoca> i would say, keep shipit label, but assign it when it gets 'works_for_me' <= at least implies testing
19:40:40 <gregdek> smooge: hey now :)
19:40:52 <rbergeron> well, so: how much do we want these labels to line up with ansible/ansible labels?
19:41:06 <rbergeron> or "not ready to cross that chasm yet"
19:41:06 <gregdek> well, it's fine now, people understand it
19:41:28 <gregdek> I don't want to gratuitously break a system that mostly works.
19:41:37 <rbergeron> gregdek: maybe ....
19:42:01 <rbergeron> gregdek: label it for "nextmeeting" -- and if it gets approved, then it gets a shipit label?
19:42:13 <rbergeron> as in: people can still type shipit, because *they* believe it can be shipped
19:42:26 <rbergeron> goes to a meeting and gets the final shipit thumbs up from core team, and then shipped.
19:42:40 <rbergeron> becadue presumably they won't always be able to press the merge button right that second
19:42:53 <rbergeron> or maybe they should
19:42:55 <bcoca> rbergeron: should be no lag from approval to merge, don't think that merits a label
19:43:01 <gundalow> Labels + actual words wolud be good, e.g. +ship it "I've reviewed the code and tested this inside Docker and it's good, I'm happy with initial tests"
19:43:12 <bcoca> if we cannot click 'merge' we should not be approving
19:43:36 <gregdek> a bot can't parse arbitrary words.
19:44:00 <gregdek> The goal of "shipit" is a better filter for the core team.
19:44:00 <gundalow> Does the bot need to do everything?
19:44:10 <gregdek> The bot needs to be a good filter for the core team.
19:44:45 <gregdek> Because if we have made the decision that the core team approves all commits -- and we have made that decision -- then the goal is to get them the best and most maintainable triage filters.
19:44:49 <rbergeron> bcoca: will yo ualways be able to merge immediately? no time spots like "well, after we ship ansible 4.0 next week then we can merge these new things" ?
19:45:41 <gregdek> There is no way for us to guarantee, ever, that a contributor saying "shipit" will always be right. It just means that we've got a better chance of it.
19:45:45 <gundalow> OpenStack have some good stuff around this. They require +2 votes. When you have 30 minutes to do some reviewing you look for PRs with +1 and give them an extra +1 so they can be pulled into the next release
19:46:02 <rbergeron> gregdek: i think that the words should still be shipit by folks in the community -- what label we apply to imply things may need a better word than "shipit" when it's going to the core team
19:46:03 <gregdek> Which we have around new modules.
19:46:11 <rbergeron> but it's still basically them saying "we believe this is shippable"
19:46:18 <gundalow> http://docs.openstack.org/infra/manual/developers.html#code-review
19:46:20 <gregdek> I don't want to change terms that are already well understood.
19:46:34 <gregdek> gundalow: we are *not* implementing that much process because we don't have the tools to support it.
19:47:00 <gregdek> And because everyone who works in openstack is basically full-time openstack. That's not the case in the ansible community at all.
19:47:22 <gundalow> gregdek: sure, valid point, just throwing in 2c about how I've seen other projects do stuff sucessfully
19:47:52 * rbergeron nods
19:47:55 <gregdek> we're taking some of those pieces. :)
19:47:58 <gregdek> But we can't take all of them.
19:48:04 <rbergeron> okay, so:
19:48:05 <gregdek> anyway...
19:48:06 <gundalow> I think they have 14 people that can merge PRs
19:48:09 <gundalow> anyway :)
19:49:32 <gregdek> rbergeron is afk for a bit...
19:50:15 <bcoca> rbergeron: if we are in a 'freeze' period we should not be doing approvals anyways
19:50:24 <gregdek> Well, looks like rbergeron needs to run to handle stuff.
19:50:47 <gregdek> bcoca: that's right, but we can handle that at some point with messaging. Fix the bot to change "shipit" messaging.
19:51:10 <gregdek> It's ok for shipit to mean different things at different times, but we have to message appropriately.
19:51:13 <bcoca> gregdek: to the point of having 'approved' label, outside of shipit
19:51:15 <gregdek> And we have to be clear internally.
19:51:24 <gregdek> I don't know what that means.
19:51:44 <bcoca> ^ above adding a 'approved by meeting' and not merging right away
19:51:55 <bcoca> if we are not going to merge, we should not be approving
19:52:07 <gregdek> WHo is "we"?
19:52:22 <rbergeron> okay, i have to go pick up my sprained ankle child at school
19:52:26 <gregdek> thx rbergeron
19:52:35 <bcoca> gregdek: those meeeting to approve a merge?
19:52:40 <rbergeron> while not rolling my eyes at her and wondering what homework she didn't do for 7th hour
19:52:41 <bcoca> ^ imagne commiters
19:52:56 <gregdek> bcoca: so this may be a separate meeting.
19:53:25 <bcoca> not sure what approval meeting is for then?
19:53:33 <gregdek> New modules.
19:53:44 <gregdek> We're not talking about new modules in this case.
19:54:00 <gregdek> For existing modules, the workflow is pretty simple:
19:54:01 <bcoca> :confused:
19:54:45 <gregdek> The meeting we had at 2pm today was to talk specifically about New Modules.
19:54:53 <gregdek> Other PRs are basically working. Not perfect, but working.
19:55:13 <gregdek> We've got community reviewers, and when they say "shipit", we forward to core team.
19:55:20 <gregdek> Sometimes they get kicked back, but mostly they go through.
19:55:39 <gregdek> And when they get kicked back, we mostly know what to do: goes back into needs_revision.
19:56:00 <gregdek> Right?
19:56:16 <gregdek> Your current triage mechanism for that seems fine.
19:56:35 <bcoca> mostly
19:57:07 <gregdek> But the mechanism for New Modules doesn't work for a variety of reasons -- mostly because the bar is, and should be, higher, for a bunch of new code that no one on the core team has ever seen.
19:57:37 <gregdek> The New Module meeting is to help us get better at that. The PR process for existing modules, while still less than perfect, is Mostly Good Enough. I just want to make sure it's documented.
19:57:55 <gregdek> Make sense?
19:58:44 <gregdek> (we also flipped over from "new module review meeting" at 2pm to "community working group meeting" at 3:15pm, so that could also be confusing, sorry about the context switch)
19:58:49 <bcoca> just an extra review meeting, but rest of proccess is same?
19:58:59 <gregdek> I believe so.
19:59:13 <gregdek> To get more eyes on new modules, which tend to sit around forever
19:59:33 <gregdek> (90% of our >6mo PRs in Extras are new modules)
19:59:46 <bcoca> bugs get more attention
19:59:54 <gregdek> as they should :)
19:59:59 <gregdek> And they also have Reviewers of Record.
20:00:08 <bcoca> i would say more bug PRs are open, but we also close them a LOT more often
20:00:25 <bcoca> ^ both cause of reviewers and people pinging core about issues
20:00:34 <gregdek> The fundamental difference from a process perspective is that existing modules *have owners who are responsible for them already* and thus are more likely to be handled.
20:00:38 <bcoca> new modules are easy to download and use, so lees pressure
20:01:22 <gregdek> If there's a problem with a PR for an existing module, it's easy: we're either harassing the submitter, or we're harassing the maintainer. Either way, we always know who has the ball.
20:01:42 <gregdek> With PRs for new modules, it's just "whoever decides to review", and if that's nobody, the PR sits.
20:02:14 <gregdek> It's that latter problem that I'm trying hardest to fix currently.
20:02:27 <gregdek> Anyway. :)
20:02:43 <gregdek> My brain is burnt and rbergeron is gone, so I'm calling the meeting. :)
20:02:45 <gregdek> #endmeeting