19:14:01 <rbergeron> #startmeeting community working group
19:14:01 <zodbot> Meeting started Wed May 25 19:14:01 2016 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:14:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:14:01 <zodbot> The meeting name has been set to 'community_working_group'
19:14:04 <rbergeron> #chair gregdek
19:14:04 <zodbot> Current chairs: gregdek rbergeron
19:14:38 <rbergeron> #topic agenda
19:14:42 <rbergeron> #link https://waffle.io/ansible/community
19:15:02 * gundalow waves
19:15:30 <gregdek> Oh hai!
19:16:04 <gregdek> What's our first ish?
19:16:57 <rbergeron> i have no idea! steve is yapping at me about stupid dishwasher buying
19:16:58 <gregdek> Almost... At... Keyboard... So... Close
19:16:58 <rbergeron> sigh
19:17:04 <gregdek> Lol
19:17:14 <bcoca> rbergeron: i have family in GE, can get discount
19:18:00 <rbergeron> bcoca: good to know, i will make a mental note of that
19:18:09 <rbergeron> i was just hoping we could get a dish washer
19:18:16 <rbergeron> like, who will put dishes in the dishwasher for me
19:18:18 <rbergeron> but alas
19:18:39 <abadger1999> rbergeron: what, You don't just do $ sudo steve_do_the_dishes      in your house?
19:18:42 <bcoca> ^ that is why my father has kids
19:18:50 <gregdek> OK!
19:18:55 <gundalow> Do we need a standing agenda for this meeting, or is it always the waffle board?
19:19:03 <gundalow> Do we need a standing agenda issue for this meeting, or is it always the waffle board?
19:19:05 <rbergeron> I think the waffle board is fine.
19:19:07 <gundalow> cool
19:19:12 <gregdek> Waffle board is good yeah.
19:19:21 <gregdek> Contrib Summit planning!
19:19:31 <rbergeron> yes.
19:19:41 * rbergeron just realized the thing she was supposed to work on she forgot about, fail
19:19:45 <rbergeron> #topic contributor summit planning
19:19:56 <gregdek> community/93
19:20:03 <rbergeron> #link https://github.com/ansible/community/issues/93
19:20:08 <gregdek> So.
19:20:16 <rbergeron> #link https://public.etherpad-mozilla.org/p/ansible-summit-july-2016
19:20:22 <rbergeron> not a ton of feedback here just yet.
19:20:23 <gregdek> we sent out the etherpad to a few folks to get it started
19:20:30 <gregdek> So some folks had their say.
19:20:35 <gregdek> And we have a not-blank doc. :)
19:20:39 <gregdek> Now it's time to open it up.
19:20:40 <rbergeron> woot
19:20:53 <gregdek> I will send to ansible-devel in the next day or two, and then the real fun can start!
19:21:05 <gregdek> Thanks to gundalow and mordred for their comments.
19:21:10 <gundalow> nps
19:21:18 * bcoca starts starving the trolls
19:21:26 <gundalow> Are you happy with lots of things, then it gets trimmed down a bit
19:21:30 <gundalow> via the voting process?
19:21:31 <rbergeron> and jhawkesworth
19:21:33 <gregdek> gundalow: yes. more things is better.
19:21:39 <gregdek> Oh and jhawkesworth!
19:22:04 <jhawkesworth> hello, just let me catch up
19:22:05 <rbergeron> we should ask people to add their names somehow, since people leave the etherpad and then ????? no idea who typed things, sometimes
19:22:20 <gundalow> It's a bit crap how by default it reuses colours
19:22:27 <rbergeron> jhawkesworth: we were just commenting that we were grateful for your notes in the summit planning etherpad :)
19:22:29 <gregdek> Yeah, etherpad can kinda suck sometimes, especially if folks aren't used to it.
19:22:45 <gundalow> Is there anyway to require a login?
19:22:46 <gregdek> jhawkesworth: yes, no action required, just a thank you ;)
19:22:56 <jhawkesworth> ah yeah with you now!
19:22:57 <gregdek> gundalow: maybe, but that would kind of defeat the purpose
19:23:05 <gundalow> suppose :(
19:23:13 <gregdek> anyway :)
19:23:17 <gundalow> PROGRESS
19:23:22 <gregdek> we've got some stuff, and soon we'll have some more stuff.
19:23:28 <gregdek> and at some point it will be soup!
19:24:00 <gregdek> Also should send a reminder to ansible-devel and ansible-project that cfp closes next week
19:24:13 <gregdek> I can do that, should be quicl
19:24:14 <rbergeron> gregdek: who should do that?
19:24:16 <gregdek> quick
19:24:21 <jhawkesworth> maybe more dev head space available now 2.1 is out
19:24:23 <gregdek> And I already sent something similar to meetup leads
19:24:33 <rbergeron> #action gregdek to remind ansible-devel / ansible-project that cfp for ansiblefest closes next week
19:25:42 <gregdek> ok
19:25:44 <gregdek> what's next?
19:25:56 <gregdek> module maintainer guidelines!
19:26:05 <gregdek> #info module maintainer guidelines
19:26:14 <gregdek> https://github.com/ansible/community/issues/81
19:26:25 <gregdek> rbergeron: any eta on a draft?
19:26:28 <rbergeron> as noted, i fail -- but i will do that this afternoon after the meeting. other things clogging brain this week :)
19:26:32 <rbergeron> gregdek: this afternoon? :)
19:26:45 <gregdek> Heh. It's not urgent.
19:26:46 * rbergeron totally spaced on it
19:26:50 <gregdek> It is important, though.
19:27:04 <gregdek> But hey! We haven't had it for TWO YEARS so another few days is not gonna kill anybody.
19:27:05 <rbergeron> yeah, but i have time and it's now in my head, so afternoon seems like a good time right now :)
19:27:09 <gregdek> Ding!
19:27:12 <gregdek> There we are, then.
19:27:37 <gregdek> Very good.
19:27:38 <gregdek> Next!
19:27:59 <gregdek> #topic OH HAI ANSIBLE PHX MEETUP
19:28:17 <rbergeron> is this pick on robyn hour? :)
19:28:21 <gregdek> https://github.com/ansible/community/issues/42
19:28:24 <gregdek> Evidently!
19:28:31 <rbergeron> we are all set, afaik, i am waiting on toby to send me the ifo about location so i can, like, update it.
19:28:33 <gregdek> But you've got a date for this one, so I think that's it, yes?
19:28:38 <gregdek> good enough.
19:28:53 * gregdek goes to add Ansible Durham work item
19:28:56 <rbergeron> i think 6/22 is what he was getting from insight.
19:29:06 <rbergeron> Insight. the company. who has the nice space and free foods.
19:29:34 <gregdek> YUM
19:29:36 <rbergeron> so once i have that, then it's officially onnnnn
19:30:09 <gregdek> like donkey kong.
19:30:11 <gregdek> NEXT!
19:30:24 <gundalow> lol
19:30:32 <gregdek> #topic Travis performance
19:30:48 <gregdek> https://github.com/ansible/community/issues/47
19:30:57 <gregdek> So gundalow has done a bunch of legwork here, thanks for that.
19:31:02 <gundalow> nps
19:31:11 <gundalow> #chair
19:31:14 <gregdek> Thanks to him, we now have quotes in front of the core team -- but they're also looking at other options.
19:31:19 <gregdek> #chair gundalow
19:31:19 <zodbot> Current chairs: gregdek gundalow rbergeron
19:31:47 <bcoca> we've also been moving tests to shippable
19:31:47 <gregdek> So for now, i think this is probably on hold. It's been more of a tracking/research item, and now it's on our plate to decide What Is To Be Done.
19:31:59 <gundalow> #info Received quotes for Travis performance. Core Team are looking at this, and other options
19:32:27 <gregdek> Right. So the engg team needs to decide "moar travis" or "moar shippabull".
19:32:52 <gregdek> So gundalow, with your leave, I'm going to close 47. I think you've carried us as far as we can go there.
19:32:55 <gregdek> Any objection?
19:32:58 <bcoca> also looking at pricing to expand resources
19:33:02 <gundalow> #info Docker images now include dependencies (mysql, etc) for tests. Which will shave off the tests. Until the packages get updated and apt/yum has to install newer versions due to state=;atest
19:33:27 <gundalow> gregdek: There are lots of things (a-h) tracked under #47
19:33:53 <gundalow> only (a) and (b) are about Travis itself
19:33:54 <gregdek> Oh. Did that change?
19:34:08 <gregdek> We might want to consider breaking that up into different issues then.
19:34:22 <gundalow> aye, I sort of abused the ticket a bit, just so I had somewhere to track everything :(
19:34:28 <gundalow> which I know is naughty
19:34:40 <gregdek> LOL
19:34:45 <gregdek> Truth?
19:34:51 <gregdek> We need a testing working group.
19:34:53 <gundalow> but it was my ticket and I'll do with it what I want
19:34:53 <gregdek> Like, yesterday.
19:35:00 <gregdek> I DO WHAT I WANT
19:35:12 <rbergeron> lol
19:35:20 <rbergeron> so when are we starting the testing working group?
19:35:23 <gregdek> https://s-media-cache-ak0.pinimg.com/736x/58/ab/9d/58ab9d580b07f5ffcf75764bb8576b7c.jpg
19:35:37 <gregdek> It's on the board for contributor summit!
19:35:43 <gundalow> yup
19:35:48 <gregdek> ok.
19:36:09 <gregdek> So what if we rename this issue to "Testing Working Group" in anticipation of breaking it out / moving it over?
19:36:18 <gundalow> gregdek: that sounds good
19:36:23 * gundalow does so
19:36:26 <gregdek> :)
19:36:36 <gregdek> That, then, is our set of opens.
19:36:47 <gregdek> #topic open floor
19:37:11 <gregdek> Anything anyone want to discuss? If not I may propose looking through ready/backlog.
19:37:20 <gundalow> https://github.com/ansible/community/pull/105
19:37:35 <gundalow> https://github.com/ansible/community/pull/105/files?short_path=5aea81d#diff-5aea81da571c7805614c028947fe5ecf
19:37:38 <gundalow> better link
19:38:19 <gregdek> Oh, good idea.
19:38:30 <gregdek> Do we actually have a "meeting_agenda" label yet?
19:38:34 <gundalow> yup
19:38:39 <gundalow> click the link :)
19:38:40 <gregdek> Wow!
19:38:48 <gundalow> not sure who added it
19:39:00 <gundalow> does require us to remember to add the label
19:39:04 <gundalow> but I think that's fine
19:39:08 <gregdek> Merged. Good job.
19:39:13 <gundalow> sweet
19:39:14 <gundalow> thanks
19:39:17 <gregdek> thank yo!
19:39:19 <gregdek> you.
19:39:20 <gregdek> grr.
19:39:25 <gregdek> thanks, yo!
19:39:54 <rbergeron> lol
19:39:59 <rbergeron> good recovery
19:40:10 <gundalow> haha
19:40:12 <gundalow> NEXT
19:40:41 <gregdek> What else?
19:41:01 <gregdek> The big thing on my mind is community/102.
19:41:14 <gregdek> Which is a public proposal for the core/extras split in 2.2.
19:41:33 <gregdek> We've had some inside the fenceline discussions, but it's time to get a proposal.
19:41:46 <gregdek> I *think* someone on the core team has this assigned now... newtMcKerr, any comment?
19:41:47 <rbergeron> #link https://github.com/ansible/community/issues/102
19:42:07 <gundalow> oh, some detail on that would be good
19:42:24 <gregdek> I agree.
19:42:28 <gregdek> And we'll get some soon.
19:42:47 <gundalow> \o/
19:43:30 <gregdek> Well, that's the hot stuff from my end.
19:43:56 * rbergeron raises an eyebrow
19:44:00 <rbergeron> okay!
19:44:01 <gregdek> Might also be worth reviewing current state of triage-bot next time.
19:44:11 <rbergeron> i have not much else. (but yes, triagebot plz, plz plz)
19:44:22 <gundalow> oh, is works_for_me, meets_guidelines part of that?
19:44:25 <jhawkesworth> interested if this means that modules core will go into ansible core?
19:44:27 <gregdek> Yep.
19:44:38 <gregdek> jhawkesworth: that's part of the proposal, but I'm not sure yet!
19:45:06 <gregdek> I think the idea of record is "core modules go into ansible/ansible and extras module stay as a separate repo and become a separate package".
19:45:16 <gregdek> But there's a lot to do to get there!
19:45:24 <gundalow> devil in the detail
19:45:31 <gregdek> So more soon.
19:45:33 <alikins> I don't think there is much of a plan yet, other than general agreement that 'getting modules into *-core or *-extras is more difficult than it should be' and 'huh, ansible-modules-* doesn't make much sense anymore'
19:45:54 <gregdek> alikins: in truth, there's always been a rough plan.
19:45:57 <jhawkesworth> ok.  first thoughts is separating the technical moving stuff around from the process changes would be A Good Thing
19:46:35 <alikins> gregdek: there are many rough plans. there is not _a_ plan
19:46:47 <jhawkesworth> I can see there being some fun round splitting up tests for example
19:46:49 <gregdek> The rough plan has *always* been "when extras grows too big we will split it off and deliver it separately." We've been talking about that since the original split. Now it's time to make that plan real.
19:47:10 <gregdek> Yep, there will be some pain.
19:47:12 <jhawkesworth> I know I'm guilty of using extras modules in tests for core modules (integration tests that is)
19:47:17 <gregdek> And it may turn out to be a multi-release thing.
19:47:32 <gundalow> jhawkesworth: oh, will be interesting to see what breaks
19:47:50 <alikins> gregdek: (not that I disagree with whatever the plan[s] are)
19:48:23 <gregdek> You're quite right that we'll have to know what the plan *actually* is before we can actually agree or disagree with it. :)
19:48:37 <gregdek> So that's what we need to get to next.
19:49:42 <gregdek> All right.
19:49:47 <gregdek> Anyone else have anything pressing?
19:49:56 <gregdek> If not, we can wrap it up.
19:50:03 <alikins> anyone know anything about the status of planned issuebot?
19:50:48 <rbergeron> i think we'rewaiting to hear back from resmo a bit.
19:51:11 <bcoca> lately its mislabeling a lot, and after we manually fix, it mislables again
19:51:13 <resmo> well, status is still the same,
19:51:20 <bcoca> ^ its been creating more work than it saves
19:51:35 <rbergeron> bcoca: issue bot or prbot?
19:51:50 <bcoca> i thought they were the same, but guessing its prbot then
19:52:07 <resmo> the main issue on triaging issues is about find out the maintainers, so what "module" is related
19:52:41 <resmo> especially with the existing issues
19:52:49 <gregdek> Right. The only thing we can do is be pretty aggressive in triage.
19:53:09 <gregdek> We can get together and do a review of existing bugs, once we decide what the right path for new bugs is.
19:53:20 <gregdek> alikins submitted a PR that I presume does some of this.
19:53:21 <resmo> imho it can not be solved easily with code, we need to do it manually in the first place
19:53:40 <gregdek> What can be solved is that we can bounce back issues that don't have actionable data.
19:53:51 <gregdek> "Sorry, we can't help you until we know what module you're talking about."
19:54:20 <rbergeron> yup.
19:54:26 <resmo> ack
19:54:34 <bcoca> the forms have helped a lot with that, but some people still just 'my playbook is broken'
19:54:51 <gregdek> and we need to start flagging those for more info, and close them if we don't get it.
19:55:05 <rbergeron> and we can always give things a label like "needs help" or "needs triage" and maybe have a small team of nice humans who might get interested in helping move those things along where people aren't sure what is broken or how to figure out what to type.
19:55:11 <gregdek> Or put in some separate "someday" bucket.
19:55:25 <gregdek> But we should *always* privilege those users who give us the right data.
19:55:27 <rbergeron> gregdek: do we ust want to have a day of plowing through existing issues?
19:55:33 <gundalow> If people enter crap, then we don't have to feel back about those issues/PRs taking longer to be processed
19:55:48 <alikins> gregdek: doesn't do much of that yet  (aside from an experiment extracting tracebacks), but there are some options. May be difficult to avoid some false positives though...
19:56:04 <gregdek> gundalow: exactly.
19:56:13 <gregdek> Right now, we don't have a happy path for *anybody*.
19:56:17 <gregdek> First, create the happy path.
19:56:23 <gregdek> Second, encourage people to get on it.
19:56:31 <gregdek> Third, figure out outliers and deal with them however we can.
19:57:00 <gundalow> +1000000000000000000
19:57:09 <gregdek> So. resmo, you still have the ball on this -- do you still want it, or are you happy to pass it off?
19:57:17 <bcoca> unlabled == needs triage
19:58:08 <alikins> I would like to get some changes into core along the lines of 'ansible --version' but for playbook. Something that could dump the modules used by a playbook for ex
19:58:50 <resmo> gregdek: I am still on it, but would appreciate if anyone is helping out
19:59:05 <alikins> I'm interested
19:59:08 <resmo> must not be a one man show
19:59:19 <gundalow> I've got to ditch now, chat tomorrow
19:59:32 <gregdek> OK, alikins and resmo, y'all can sort it out :) (resmo, might want to have a look at alikins PR as a start)
19:59:33 <resmo> alikins: we should coordinate
19:59:36 <gregdek> bye gundalow thanks!
19:59:36 <bcoca> alikins: i have a callback that grabs stats, i need to clean it up ans submit
19:59:57 <gregdek> https://github.com/ansible/ansibullbot/pull/95
20:00:15 <resmo> speaking about the bot, I also thought about comments should have a prefix to reduce false positive
20:00:22 <resmo> gregdek: tag:shipit
20:00:27 <resmo> e.g
20:00:28 <gregdek> :)
20:00:42 <gregdek> resmo I agree about prefixes, false positives have been problematic
20:01:02 <bcoca> ^ lets remove shipt as a comment
20:01:03 <gregdek> The problem is you have to tell users what to do, LOL
20:01:24 <gregdek> bcoca: to be replaced with what?
20:01:39 <MichaelBaydoun> once this pr recieves two "ship its" without the space ...
20:01:46 <resmo> gregdek: we should have some docs about the bot, what it does and how... for users
20:01:53 <bcoca> what we agreed in meeting? tested/meets guidelines
20:01:55 <gregdek> MichaelBaydoun: right :)
20:01:59 <bcoca> ^ i forget exact terms
20:02:05 <gregdek> bcoca: that's only for new modules though.
20:02:17 <gregdek> For existing modules, the maintainer should be able to use shipit.
20:02:21 <bcoca> gregdek: why not all PRs?
20:02:33 <MichaelBaydoun> nitzmahone> #accepted - we will use tested_working and meets_guidelines as comment tags
20:02:37 <bcoca> well, i would still expect  a 'tested' or 'reviewed'
20:02:44 <bcoca> shipit says ... not much
20:02:48 <alikins> bcoca: a callback module for gathering 'info useful to fix/track a bug'... I like it.
20:02:55 <gregdek> Because it's the maintainers job to decide how to maintain a module?
20:03:04 <bcoca> alikins: its mostly 'modules used and how many times'
20:03:28 <gregdek> We want the least amount of process we can have while still being effective.
20:03:41 <bcoca> gregdek: lots of 'shipit' have ended up being 'i like the idea but i did not even look at the diff nor test it'
20:03:48 <gregdek> Why would I ask resmo to give me two different things for a cloudstack module when he can just say "shipit"?
20:03:53 <bcoca> ^its nice to konw going in if there was actual testing or just review
20:04:01 <gregdek> bcoca: then that's on the maintainer.
20:04:09 <gregdek> Also:
20:04:13 <bcoca> gregdek: then lets not do it in core
20:04:20 <gregdek> These can (and maybe should) be different in core and extras.
20:04:24 <bcoca> ^ cause it has caused issues
20:04:36 <gregdek> If you want to stop using shipit in core, that's fine by me.
20:04:49 <bcoca> and even in extras, we are still merging them in by core team, would save us much time on review
20:05:14 <bcoca> resmo is bad example as he has demonstrated over long time that he is responsible, so have others, but not nearly all maintainers
20:05:18 <alikins> resmo,gregdek: One idea I had about the bot comments... may be useful for the bot to add some extra meta info into it's comments, and it could easily add those inside the *ml comments ('<!-- >')...  to avoid visual/info noise
20:05:26 <bcoca> i would say he is in minority
20:05:27 <resmo> bcoca: :)
20:05:39 <bcoca> resmo: just calling it how i see em
20:05:48 <bcoca> you earnt the trust
20:06:49 <bcoca> gregdek: when we separate extras and core has no responsibility, i'm fine with however its dealt with, but now we are still the ones getting poked at when there is an issue
20:06:59 <alikins> resmo, gregdek: for example, the version of the prbot that made the comment
20:07:01 <gregdek> Ok, bcoca. I understand.
20:07:21 <bcoca> and lately its been a lot of work to 'correct' prbot
20:07:50 <gregdek> Perhaps now is the time to fork the triage bot, and have one for core and one for extras, because they will likely have different processes at some point anyway.
20:08:17 <resmo> gregdek: yep
20:08:26 <gregdek> And it's very likely time for me to hand off the responsibility anyway.
20:08:26 <newtMcKerr> @gregdek here now, sorry.
20:08:56 <resmo> gregdek: as long as extras ships with ansible, it should be the same process
20:08:57 <gregdek> I was helping to support the core team when the core team was three. Now the core team, with community members, is 15+. Definitely large enough to decide how better to manage their PRs.
20:09:13 <gregdek> resmo: but the time is coming, soon, when extras will not ship with ansible.
20:10:24 <rbergeron> so: what's the action item / decision here?
20:11:00 <gregdek> I think it's up to the core team to figure out how they want to do triage on core modules.
20:11:02 <gregdek> We can:
20:11:06 <newtMcKerr> yes.
20:11:07 <gregdek> 1. Turn off triage on core modules;
20:11:27 <resmo> I am -1 here
20:11:40 <gregdek> 2. Fork triage.py and have separate runs for core and extras, with codebases diverging over time;
20:11:55 <gregdek> 3. Keep triage.py and incorporate different logic for core vs. extras;
20:12:13 <gregdek> 4. Leave things as-is for now until we have more data/plans.
20:12:45 <newtMcKerr> I lean towards two, but I wouldn’t mind begging a week or so to circle that up and make sure.  talk to people, etc
20:13:09 <gregdek> For all of these, we must also ask the question: who maintains the bot?
20:13:13 <resmo> gregdek: imho the biggest issue is about ansible core member comments feature. revert?
20:13:33 <gregdek> bcoca: what is your biggest issue?
20:14:01 <gregdek> resmo: I don't want to revert until I know what the problem actually is -- and I suspect it's more "people give shipits when they're not warranted," which is less a bot issue and more of a process issue.
20:14:06 <bcoca> its a confluence, old shipits getting a shipit label every time it runs, even after changing it manually
20:14:17 <bcoca> same thing with 'broken tests' setting a pending action
20:14:24 <bcoca> ^bot should respect manual changes
20:14:38 <gregdek> One thing we could do:
20:14:42 <alikins> 'core member comments feature' ?
20:14:45 <bcoca> and use of 'shipit' which is a 'social issue'
20:14:47 <resmo> alikins: https://github.com/ansible/ansibullbot/pull/85
20:15:05 <bcoca> or just detect that shipit was removed AFTER it had been triggered set by comment
20:15:14 <bcoca> ^ bot should be smart enough to look at ticket timeline
20:15:26 <gregdek> Bot does have some of those smarts. We just need to set the logic.
20:15:30 <gregdek> Should be doable to say:
20:15:35 <bcoca> and only act when 'non acted on trigger' appears
20:16:06 <gregdek> "If any core team comment comes after any shipit, unflag shipit".
20:16:19 <gregdek> Would that rule work?
20:16:28 <bcoca> no, i would say if anyone removed 'previous shipit' don't do shipit
20:16:35 <bcoca> unless new comments
20:16:49 <gregdek> But we have no way of detecting if "someone removed shipit" currently.
20:16:58 <bcoca> you can see ticket action history
20:17:25 <gregdek> resmo can you look at action timeline as well as comment timeline?
20:17:33 <gregdek> I was never able to, but maybe you can
20:17:34 <bcoca> #1 creatd, #2 shpiit comment #3 bot sets shipit label #4 someone removes label, #2 should not trigger another 'shipit' label
20:17:45 <gregdek> yes, i understand
20:17:51 <alikins> anyone got pointers to example pr's that show the wrong behavior?  I'm interested in fixing it
20:18:03 <gregdek> That presumes we can accurately detect #4
20:18:11 <bcoca> i posted a couple in core this week, i'll send you ones as i find them
20:18:12 <alikins> or better, reference them in an ansibullbot issue
20:18:17 <gregdek> +1
20:18:26 <bcoca> ^ will do
20:18:43 <gregdek> I'll create the issue, one sec
20:19:35 <gregdek> https://github.com/ansible/ansibullbot/issues/97
20:19:49 <bcoca> https://developer.github.com/v3/issues/events/#list-events-for-an-issue
20:20:03 <bcoca> you can see labels on each 'event'
20:20:21 <alikins> resmo: you mentioned you had ongoing work on issuebot. is there a branch I could take a look at?
20:20:29 <gregdek> bcoca if we can resolve this, does this solve your current "shipit" problem for now?
20:20:48 <resmo> alikins: didn't publish it yet, I'll ping you when ready
20:20:53 <bcoca> well, diff issues, one is on using shipit as a comment
20:21:05 <bcoca> the other is bot being smarter
20:21:43 <gregdek> I know you're not happy with shipit as comment. I think that's a larger debate, but if you really don't want that for core, then it's time to fork and implement a separate process. Which is ok and will need to happen eventually.
20:21:47 <resmo> or less smarter than the humans :)
20:21:53 <gregdek> Because for extras, if anything, the process will get looser.
20:22:16 <bcoca> gregdek: and i'm fine with that, once we separate, right now it just creates more work for me
20:22:22 <gregdek> Yep.
20:22:35 <gregdek> I think we're on the same page. It's just about what's expedient for now.
20:23:04 <gregdek> I'm happy if you guys want to fork core and start implementing your own stuff, but I don't have the cycles for that, and resmo has been graciously taking so much of this work on anyway.
20:23:22 <gregdek> s/fork core/fork a version of triage bot for core/
20:26:01 <gregdek> So.
20:26:08 <gregdek> Let's have some takeaways.
20:26:13 <gregdek> We've already got issue 97.
20:26:28 <gregdek> #action bcoca will find shipit reversion cases and document them in 97
20:26:43 <gregdek> #action alikins will take a look at 97 and see if he can find a fix
20:27:04 <gregdek> #action resmo and alikins will collaborate on issuebot code
20:27:25 <gregdek> #action newtMcKerr will socialize the idea of splitting triagebot into a core version and an extras version
20:27:29 <gregdek> That about it for now?
20:27:38 <newtMcKerr> works
20:27:46 <gregdek> ok!
20:27:48 <resmo> ack
20:28:02 <gregdek> thx everyone. one step closer. :)
20:28:17 <gregdek> And now that we're 1/2hr (but started 15 mins late, eh)
20:28:22 <gregdek> #endmeeting