19:00:40 #startmeeting Core Team Meeting 19:00:40 Meeting started Tue Jan 31 19:00:40 2017 UTC. The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:40 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:40 The meeting name has been set to 'core_team_meeting' 19:01:06 #chair abadger1999 alikins bcoca jtanner mattclay ryansb 19:01:06 Current chairs: abadger1999 alikins bcoca gundalow jtanner mattclay ryansb 19:01:18 * mattclay waves 19:01:40 Agenda https://github.com/ansible/community/issues/148 19:01:51 Omw 19:02:06 hi folks 19:02:11 Óla 19:02:17 #topic custodianship of the AWS modules 19:02:24 https://github.com/ansible/community/issues/148#issuecomment-276347992 19:02:27 willthames: over to you 19:02:41 thanks 19:02:57 so the rate of acceptance of AWS module PRs in particular has been pretty bad recently 19:02:57 bloop 19:03:10 e.g. 1.5 months to change Falsentry to False 19:03:41 I've imported several PRs from the old repos that are months old with no review etc 19:04:07 something is going wrong, I'm not 100% sure on how best to fix it, but more people with shipit rights, more committers, etc would be a start 19:04:27 interested to hear ryansb's thoughts too 19:04:34 just some context, i believe aws is group with most people with 'shipit' rights 19:04:45 and other modules have been languashing for longer 19:04:55 do you have *any* evidence for that first assertion bcoca? 19:04:59 ^ not saying it justifies, but this is endemic 19:05:23 https://github.com/ansible/ansibullbot/blob/master/FILEMAP.json 19:05:33 https://github.com/ansible/ansibullbot/blob/master/MAINTAINERS.txt 19:05:36 https://github.com/ansible/ansibullbot/blob/master/MAINTAINERS.txt 19:05:43 * jtanner just sat down 19:05:58 which aws module(s) ? 19:06:07 right, so lots of people with ship it rights on a *single* module 19:06:10 jtanner: https://github.com/ansible/community/issues/148#issuecomment-276347992 19:06:23 willthames: the fallback is 'grouping' 19:06:29 no one with shipit rights on cloud/amazon as a whole 19:06:33 I don't have shipit rights 19:06:35 so who dows 19:06:37 does 19:06:57 willthames: yeah, we do have lots of AWS PRs waiting, and I've been reviewing & merging, but expanding the pool of people that can review & test would help 19:07:24 another problem is zero call to review on PRs 19:07:36 willthames: they do have as a whole 19:07:45 who do? 19:07:49 those in aws 19:07:53 who is in aws? 19:08:16 * bcoca feels he is in laurel and hardy skit now 19:08:51 zero call to review? I think everyone's aware that someone needs to review PRs 19:09:00 ec2.py is 'supported_by': 'committer', ... so it can be labeled shipit, but it will never be automerge 19:09:30 and in terms of "call to review", @name in github doesn't draw people in 19:09:39 some people pay attention, most don't 19:09:55 the bot is pinging anyone explicitly listed as a maintainer though 19:09:59 sorry, not what I meant ryansb, actually you're right, there is a call to review but jtanner's point is valid 19:10:10 a lot of reviewers may no longer be at all active 19:10:11 Yeah, but we can't make community members review PRs if they don't want to 19:10:18 also that 19:10:34 and for modules with 1 maintainer, the bot is now allowing people who maintain a module in the same namespace to give a 2nd shipit ... they are also being pinged 19:10:37 no, but if community members aren't even aware there is stuff in need of review... 19:10:51 jtanner is that a new thing? 19:10:54 show me a ticket that didn't ping people 19:10:58 yes, pretty recent 19:10:58 willthames: comminity_review label? 19:11:06 the namespace change is a few days old 19:11:18 namespace pinging was within the last week or so 19:11:21 Hey, sorry I'm late 19:11:24 ^ actually thought that is how it worked all alaong 19:11:26 bcoca, was thinking more active notifications, perhaps like ansible/aws was designed for 19:11:36 define "active" 19:11:39 what about that would be more active? 19:11:44 I get an email 19:11:49 willthames: people already complain about spam 19:11:55 i can't email people through github 19:12:04 you can do @willthames and I get an email 19:12:09 ^ cc @person normally triggers email 19:12:10 that is already done 19:12:18 but not always, depends on user's settings (default is email) 19:12:22 sure 19:12:28 if you aren't a maintainer, but want to be ping'ed, you can be added to the FILEMAP.json 19:12:43 ^ we need to make that process clearer 19:12:46 I would like to be pinged on all AWS changes 19:12:50 PRs that is 19:13:01 I would like overall shipit rights on AWS changes 19:13:09 ok, file a bug in ansible/ansibot and i will make it happen 19:13:16 but notification != shipit rights 19:13:27 you need to be added to MAINTAINERS.txt for that 19:13:29 Ideally I would like commit rights too 19:13:39 jtanner: we need to move the data file to ansible/ansible and have docs point people at it for 'community maintenance process' 19:13:41 not really a new request... 19:13:49 I've emailed GitHub to ask them so we can request GitHub PRs reviews from people outside of those with commit rights, got their standard "Thanks for the suggestion" email 19:14:05 gundalow: great, we'll have in 4yrs 19:14:11 github doesn't care about repos with >10 people 19:14:24 not their target market 19:14:25 perhaps we need more AWS modules at community status 19:14:28 bcoca: aye, well they added the ability to see what reviews are assigned to you 19:14:30 community shipits still weigh in when I'm reviewing. Like, if I see a PR (as a committer) and the maintainer hasn't commented but there's community shipits that's a factor 19:14:34 clear down maintainers.txt to active reviewers 19:15:03 willthames: we have process for that, if maintainer has not responded for a while to any tickets 19:15:20 we do? 19:15:31 when was that last checked? 19:15:33 jtanner: i must have had that conversation with myself 19:15:48 jtanner: thought you had that done already ....nvmd then 19:15:48 i'd like there to be one, but i didn't write anything to make it so 19:16:01 jtanner: bcoca we have an agenda item for today regarding taking over modules, so we can talk about that after this 19:16:52 how is that even tracked? 19:16:55 gundalow: i belivve that is subset to what issues willthames brought up, some i thought we had solved a while ago ... 19:17:22 bcoca: you, I didn't want us to get sidetracked on taking over orphaned modules 19:17:25 willthames: it's not currently ... not by anything under the redhat umbrella 19:18:30 the problem with the cloud modules is the number of people who even have the ability to test them 19:18:37 i don't have accounts 19:18:41 jtanner, sure 19:18:44 I have lots now 19:18:56 which is why i don't feel the core team should be gating them 19:19:00 I have been inactive in AWS space for about two years, until the last month 19:19:24 and now I'm very active again, I see the lack of support on AWS modules 19:19:38 you were the support ... 19:19:41 some of that will be legacy, some of that will be active maintainers leaving the project 19:19:50 jtanner: I have the necessary accts, just not the necessary hours 19:19:54 jtanner and now I have 15 open AWS PRs and not much getting them through 19:20:05 hi 19:20:08 so a) we need DOCUMENTED phasing in/out of maintainers 19:20:08 most of them aren't even mine, I'm just shepherding old PRs through 19:20:13 morning resmo 19:20:38 the cloud modules aren't suffering any problems that all the other modules are not 19:20:59 bcoca, can we see how long tickets have been in waiting_for_maintainer or whatever 19:21:18 if several tickets have been waiting on same maintainer, they get dropped 19:21:25 not after a week, but after a month 19:21:27 say 19:21:44 and who replaces them? @ansible ? 19:21:47 that won't work 19:22:13 i would not replace in a month, its rare, but some people do take 1 month vacation (less rare outside USA) 19:22:21 who can do it? ryansb can, I can 19:22:31 bcoca, I did say 'say' 19:22:37 willthames: dont commit ryansb .. he has plenty on his plate 19:22:50 you'll do it this month while it's your hot ticket item, but when you job responsibilities shift again, you'll be off to different things 19:23:11 well, what's your alternative jtanner? as it appears to be no-one can do it 19:23:20 whereas i'm willing to do it 19:23:31 lets see if this is better: 1) allow new maintainer sto be added at any time , 2) after 2months of non response, maintainer gets listed for deprecation 3) after review/contact process ? he gets removed 19:23:32 and maybe in six months the project will have the same problem 19:23:42 he/she bcoca 19:23:46 jtanner: there is no way around the 'shifhting' 19:23:56 we just need to make maintainers 'phasing in' easier 19:24:13 most of the modules under cloud/aws have only 1 maintainer, so you already have shipit capability because you maintain something in there 19:24:23 cloud/amazon/ec2_snapshot.py: willthames 19:24:27 that's not true, unless that's changed in the last week 19:24:40 I added shipit to a PR and it got removed :( 19:24:45 which? 19:25:00 two secs 19:25:05 * mattclay will be away for a few minutes 19:25:14 willthames: many reason sfor removal, anyone can add 'shipit' comment but it will only count if you are maintainer 19:25:19 there's also bugs in the bot sometimes, and i try to fix those if pointed out 19:25:34 https://github.com/ansible/ansible/pull/18842 19:25:54 so you two are making completely different arguments 19:26:35 added automerge 19:26:43 ^ athat is why shipit was removed 19:26:58 no, that should have stayed 19:27:02 i'll figure it out 19:27:04 jtanner: bug then? 19:27:05 sorry, 'added automerge' makes no sense as a sentence 19:27:17 ansibot added automerge community_review 19:27:21 automerge is under review right now until we are sure the algo is correct 19:27:23 ^ labels 19:27:31 so for now, it's just a label and not an action 19:27:48 willthames: so it was working for you, bug made it go away when we were attempting to have bot set automerge 19:27:51 So automerge (the tag) is going to mean the bot will merge PRs that have the shipit label after the sufficient community/maintainer/committer shipits 19:27:59 which is not yet implemented 19:28:07 so community_review is supposed to be sufficient for shipit? 19:28:44 no 19:28:46 jtanner: we need to setup workflow diagrams 19:28:56 community_review is a state, meaning it's waiting on people to give shipits 19:29:02 ok, if it was a bug, or a not yet implemented feature, that's fine, but that PR was embarrassing 19:29:03 probably after we stop redefining workflows .... 19:29:31 if I had commit rights it would have long been sorted... 19:29:44 no, you'd be squirreled off into some other niche area 19:30:16 I meant that specific PR jtanner 19:30:36 I'm not expecting to resolve all issues with AWS PRs, I'm not a naive idiot 19:30:51 willthames: you are on the short list, but we have not set date to review current permissions, w/o bugs the 'shipit' shoudl havee been enough 19:31:11 ok 19:31:32 I'm relatively happy with your course of action bcoca 19:31:33 ^ i think bot will help more than commit privs as it gives a good balance between commit permissions and scope of them, github is all or nothing 19:31:57 bcoca, still understood from a year ago, still occasionally frustrating from a year ago 19:32:07 willthames: we are constantly trying to improve, lots of stuff going on, i though some of this was already done, sorry i was wrong 19:32:08 but that's why I turned up here, to find out what was going on 19:32:10 .oO(willthames has not commit rights??!) 19:32:22 resmo, no, still... 19:32:24 willthames: i just closed PRs over 2yrs old ... 19:32:32 o_O 19:33:10 i had to x2 check, thought we gave him last time we revised perms 19:33:15 (30 minutes) 19:33:43 "what was going on" ... summary: too many PRs and too many issues, no matter how big the core team gets. The way we're dealing with it is to give more capabilities through the bot, since github doesn't care. 19:33:43 willthames: going forward, let us know when you see this stuff, issues/pr against ansibot help 19:33:51 yep, will do 19:34:15 I think adding a mention in core's agenda also works 19:34:30 too many inactive maintainers as well jtanner 19:34:31 That way, someone can keep it on the radar 19:34:39 its also why we have these meetings ... we are always happy to merge low hanging fruit (i probably glossed over that once they resolved the merge conflict, i should have merged then) 19:35:00 means a PR languishes for months before people realise that no maintainer is looking at it 19:35:03 inactive maintainers is not a manpower problem, imo. It's a problem with us allowing too many modules into the code. 19:35:23 jtanner, really? 19:35:27 jtanner: i agree, but we are fighting windmills until ansible-installer 19:35:45 willthames: we are close to 900+ moduels .. i would have less than 60 19:35:58 wow, ok, batteries included no longer a thing eh? 19:36:03 if we keep at this pace, we are going to have a python abstraction for every concept in world of computing. We can't possibly maintain all of that. 19:36:05 ansible-aws-plugins should be it's own project 19:36:10 imo 19:36:22 Make that ansible-cloud-plugins 19:36:30 plugins or modules? 19:36:37 Because you have open stack (close to aws) 19:36:40 azure 19:36:40 allanice001: that is virtual package that includes ansible-azure-plugins, anisible-vmware.... 19:36:59 i see 19:37:13 willthames: plugins, i want to be able to also have lookup('aws_meta') ... 19:37:30 we should probably move on - where should I raise a 'cull inactive maintainers' issue? 19:37:32 willthames: and THAT package can depend on boto 19:37:35 boto3 19:37:40 i don't think "batteries" was ever meant to be "everything everyone ever wanted" 19:37:49 willthames: that is next item on agenda, gundalow has on ticket 19:37:54 ok 19:38:26 gundalow: i believe i outlined a process above, though for that user (that does not exist on github anymore) i think we are passed 3) 19:38:47 the question is, who should own by default? 19:38:59 #topic Orphaned mode process (uri) 19:39:05 ^ my vote for 'community' modules is leave orphan and have those in same category assume mantle 19:39:13 It says 'supported_by': 'core' 19:39:15 jtanner: will that work with bot? 19:39:19 gundalow: then its core 19:39:26 huh? 19:39:38 https://github.com/ansible/ansibullbot/pull/291 19:39:40 jtanner: https://github.com/ansible/ansibullbot/pull/291 19:39:47 module_utils/uri .. not module 19:39:53 and yes, that was always 'core supported' 19:39:59 feel free to remove name 19:40:27 The agenda item is about network/basics/uri.py 19:40:35 it should be @ansible 19:40:35 which currently points to romeotheriault 19:40:55 ah, that uri.py .. 19:40:59 not sure why module_utils was mentioned 19:41:19 modue_utils/uri.py .. which has most of the code uri.py and other modules that do http requests use 19:41:23 sorry, i conflated 19:41:26 nps 19:41:43 So are people happy with https://github.com/ansible/ansibullbot/pull/291 19:41:45 still, core module, its our 'generic http/restapi requests' module 19:41:46 if so I'll merge 19:41:59 happy ..NO... resigned 19:42:06 gundalow I am, but still need a way to find other inactive maintainers 19:42:30 this one is only obvious because they appear to have left github 19:42:39 which is easy case 19:42:40 willthames: If you see PRs that aren't getting pinged with everyone under cloud/amazon/ then let us know 19:43:12 * allanice001 can assist with reviews / testing of was PR's willthames 19:43:20 allanice001: Thank would be ace, thanks :) 19:43:28 S/was/aws 19:43:45 gundalow obvious example: https://github.com/ansible/ansible/pull/20214 19:43:57 thanks allanice001 19:44:21 gundalow that's probably one out of many 19:44:39 * mattclay is back 19:44:41 note that the original commits are over a year old now 19:45:00 hum, so ec2_vpc_nat_gateway_facts isn't in MAINTAINERS.txt 19:45:13 Close to 60 open containing AWS 19:45:14 jtanner: I would have expected the bot to ping everyone 19:45:28 why? 19:45:34 to ask for a review 19:45:47 on a PR without a maintainer? 19:45:50 gundalow it's a new module 19:45:57 oh 19:45:57 how do new modules get reviewed? 19:46:00 * gundalow reads the actual PR 19:46:07 jtanner: sorry, ignore me 19:46:10 +1 to adding willthames to cloud/aws maintainers 19:46:13 shouldn't the bot ping everyone? 19:46:21 https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md#new-modules 19:46:22 willthames: not everyone ... 19:46:35 bcoca, *anyone* ? 19:46:41 someone 19:46:46 "community" is defined as maintainers in the same namespace in that regard 19:46:51 someone on the list in the path for maintainership 19:47:02 but if noone knows about it 19:47:27 It's not even clear to me from that PR that that's what I should do 19:47:28 we need to document 'community_review' and probably have a 'needs maintainers' 19:47:38 ^ then link those in docs as queries for peopel wanting to participate 19:48:10 i -think- the bot should have pinged a bunch of people on 20214 19:48:13 checking 19:49:16 jtanner could it be a side effect of repomove? 19:49:34 Add @maintainer tags in doctstring perhaps? 19:49:58 it seems to have the right labels, but not the right comments from the bot 19:50:08 hrm, the bot wants to ping a bunch of people on it now 19:50:13 allanice001 problem is that goes out of date 19:50:14 because of the namespace change 19:50:29 An example cou 19:50:32 jtanner, I have a whole list of similar PRs 19:50:34 Could be """ 19:50:49 @maintainer: allanice001 2017 19:51:03 @maintainer: willthames 2017 19:51:05 etc 19:51:12 willthames: there's a skip logic to avoid re-processing issues that haven't been updated since last run 19:51:16 that's probably what happened here 19:51:29 bot_status command or any comment could trigger it to check again 19:51:54 the skip logic is one of the tactics i have to use to avoid rate limiting 19:52:23 jtanner, ok, I'll do that at a human pace over the next couple of days then :) 19:53:06 not for 20214 though as bcoca merged it - thanks! 19:53:15 was easy to review 19:53:27 sometimes you just need to ping right person at right time 19:53:42 18842's problem was that the submitter made a commit -after- the maintainer did shipit 19:53:56 then during a bot code test, shipit was added and removed 19:54:15 ^ which is how it should be 19:54:30 it was going to be re-added after you and the maintainer had redone his shipit ... but someone merged it beforce then 19:54:36 but probably bot should say that (new commit detected, shipit count reset) 19:55:14 that will kill the ratelimit 19:55:37 :-( 19:55:39 right, I need to go and sort stuff out for Paris. 19:55:48 Can someone take over chairing please? 19:55:49 bot_status will give counts as needed 19:56:11 enjoy gundalow 19:56:25 jtanner, that's not right 19:56:36 what isn't? 19:56:48 my shipit got removed after a comment 19:57:05 your shipit was the 1st one after the last commit 19:57:16 and the bot added shipit label 19:57:21 and then later removed it 19:57:26 yes, during a code revision 19:57:27 after a comment, not a commit 19:57:37 i fixed a logic bug, it re-calculated, and removed the shipit 19:57:53 ... then the maintainer added another shipit 19:57:59 bringing the count to 2 19:58:47 right, I guess the lag between commit and shipit label being removed didn't help 19:59:06 the reset logic was being implemented that day 19:59:22 I would suggest shipit1 and shipit2, but guess that's yet another rate limiting limited feature ;) 20:00:27 it is 20:00:37 object creation is severely rate limited 20:03:02 * jtanner does a full run on all PRs without the skip feature to get things re-synced 20:03:37 will probably take >2 hours 20:04:22 Okay, are we done on this topic? 20:06:23 abadger1999 I think so - bcoca, I'll raise a PR for MAINTAINERS.txt 20:06:44 not sure that I understand FILEMAP.json sufficiently to make any changes or understand if one is needed 20:07:24 if you are going add "cloud/aws: willthames" to MAINTAINERS, you don't need to change FILEMAP 20:07:52 ok 20:08:24 bcoca, do you need an issue to track inactive maintainers? 20:08:48 sorry abadger1999 I'm kind of done, just checking on actions 20:09:06 #topic PR 20737 bugfix for test-module 20:09:28 allanice001, willthames: Looks like you two are working on this right now. 20:09:37 yup 20:09:48 yep, just need to check final result 20:09:52 Final patch should be up, if willthames agrees 20:10:09 will test on my OS X laptop as brew makes for a great test case 20:10:24 Which is how I found the bug ... 20:10:31 saying that a virtualenv works fine too 20:10:43 yeah, I hadn't tested the non ansiballz case 20:10:48 not even sure how I would tbh 20:12:04 I'm working through gundalow's refactored module building docs 20:12:18 And just happen to not be in a virtualenv 20:12:23 probably a ruby module from the ansible-for-rubyists repo would test nonansiballz 20:12:34 windows module might. 20:13:01 not entirely sure about that, though as I've not tested powershell stuff out 20:13:15 BDS perhaps 20:13:16 Cool. 20:13:17 ? 20:13:35 * bcoca looks for old perl module 20:14:02 Okay, allanice001and willthames: Let me know when you're happy with it and I'll merge. 20:14:09 allanice001 is timetest.py just print json.dumps(datetime.now()) ? 20:14:19 I guess that would be non ansiballz 20:14:25 abadger1999 will do 20:14:27 yeah 20:14:38 can you put that in the PR for replication purposes? 20:14:43 Literally from the docs 20:14:45 ack 20:14:55 Would a comment suffice? 20:14:58 sure 20:15:17 we can take this off #ansible-meeting, sorry 20:15:36 np 20:16:12 Cool. 20:16:21 added 20:17:04 #topic https://github.com/ansible/ansible/pull/20058 systemd-nspawn connection 20:18:14 +1 , but wanted more eyes on it 20:18:50 disclaimer: this is in no way a waiver on my right to critisize systemd in general 20:19:18 heh 20:20:31 No problem with it in general, there's some code that needs changing as general style, python2.6 compat and such. 20:20:42 abadger1999: go2town 20:20:55 bcoca: if you're fine with the overall, I'll just review the specifics and we can merge when they fix them. 20:21:00 Cool. 20:21:41 #action systemd-nspawn connection plugin, abadger1999 will look at some specific code quality and then we can merge 20:22:08 #topic https://github.com/ansible/ansible/pull/18379 lookup plugin for system keyrings 20:22:17 bcoca: yours again 20:22:24 same deal 20:22:44 i'll add docs if merged 20:24:00 also, not sure what we want for passing args to looups anymore 20:25:54 bcoca: Looks okay to me. 20:26:24 actually.. minor nitpick.. you can change it when you do docs: 20:26:54 modify the error message to specify it's the python keyring module. 20:27:04 we have too many uses of the term module otherwise. 20:27:08 he 20:27:15 #topic Open floor 20:27:16 python keyring LIBRARY 20:27:18 https://github.com/ansible/ansible/pull/20567 20:27:21 bcoca: 20:28:36 abadger1999 https://github.com/ansible/ansible/pull/20737 is good now 20:29:30 willthames: it missing a shippable status 20:29:37 close and re-open it 20:29:52 allanice001: ^ 20:30:01 enroute 20:30:07 jtanner pretty sure we don't have reopen rights 20:30:19 the owner doesn't? 20:30:26 he just did it 20:30:27 bcoca: Looks like a nice feature.... I'm wondering if there's a noticable performance cost to it, though. 20:30:33 oh, clearly he does 20:30:38 allanice001: that did it, thanks 20:30:51 I'm sure I've made that mistake in the past and had to ask for a ticket to be reopened 20:30:57 legacy info at best I guess 20:31:33 I think I can, cause I'm a contributor for that PR 20:31:58 submitter 20:32:16 abadger1999: not that i've found, should only happen 1 per invokation 20:32:28 Submitter, yes 20:32:59 But I'm not a maintainer on something like https://github.com/ansible/ansible/pull/20214, so I can't do same there (as an example) 20:33:46 And it's not recursive either so won't hurt people who define inventory vars. 20:34:38