15:01:08 #startmeeting core-team-meeting 15:01:08 Meeting started Thu Mar 23 15:01:08 2017 UTC. The chair is jtanner. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:08 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:08 The meeting name has been set to 'core-team-meeting' 15:01:17 #chair jtanner bcoca 15:01:17 Current chairs: bcoca jtanner 15:01:28 #chair abadger1999 15:01:28 Current chairs: abadger1999 bcoca jtanner 15:01:32 yo 15:01:36 #chair nitzmahone 15:01:36 Current chairs: abadger1999 bcoca jtanner nitzmahone 15:01:58 now i need to find the agenda ... 15:02:02 Óla 15:02:14 https://github.com/ansible/community/issues/156 15:02:37 jtanner: any updates on shipit workflow? 15:02:51 o/ 15:02:57 #chair rcarrillocruz 15:02:57 Current chairs: abadger1999 bcoca jtanner nitzmahone rcarrillocruz 15:03:03 hi 15:03:04 #topic shipit workflow 15:03:10 #chair shertel 15:03:10 Current chairs: abadger1999 bcoca jtanner nitzmahone rcarrillocruz shertel 15:03:16 bcoca: in what context? 15:03:24 https://github.com/ansible/community/issues/156#issuecomment-283631658 15:03:46 does everything have meta now? 15:03:47 was waiting for 'metadata rework' whatever that means, and that is done, seems like bot woudl be next? 15:04:28 #info plugin metadata is done 15:04:43 #action jtanner to evaluate and write bot workflow for non-module shipits 15:05:33 #info https://github.com/ansible/ansibullbot/issues/437 15:06:14 bcoca: what has meta in it? 15:06:32 nothing that i know of, not sure what that comment means 15:06:56 not sure how to insert 'metadata' in ini/yaml files 15:07:12 ^ i personally think we are better off tracking this with maintainers in external file 15:07:49 why was it dependent on "metadata rework" then? 15:08:19 ^ just said, idk 15:08:58 i don't know 15:09:14 it's too early to talk/argue about metadata though, so i want to move to next topic 15:09:40 k 15:09:50 skiping a few due to missing/no updates 15:10:12 i can't read this agenda ticket 15:10:13 https://github.com/ansible/community/issues/156#issuecomment-283632351 15:10:19 #topic proposing proposals 15:10:38 allanice001? 15:10:53 ^ everyone read https://github.com/ansible/proposals/pull/59 ? 15:11:23 i've read it 15:12:04 s/committee/team/ 15:12:13 We don't operate by consensus 15:12:18 we try 15:12:55 But maybe "we attempt to operate by consensus of its members; falling back on a vote of the members if a bottleneck is reached"? 15:12:55 things might end up beind 'decided' by core ansible team or james, but we rarely use that, its mostly tie breaker 15:12:56 i think it's trying to deliver the false promise that a long defined process is somehow going to get PRs merged faster 15:13:12 s/bottleneck/impasse/ 15:13:43 i dont disagree, i was going for something that put onus on submitter to push thorugh (mirrors more what actually happens now) 15:13:50 I don't think we're going to have acceptance tests and multiple implementations. 15:14:01 that made me chuckle 15:14:02 Proposals is really more about getting the specification/design done 15:14:08 community demand should be a major factor in taking a new feature 15:14:18 jtanner++ 15:15:20 We aren't likely to see many proposals with formal spec language either. 15:15:26 #chair mattclay 15:15:26 Current chairs: abadger1999 bcoca jtanner mattclay nitzmahone rcarrillocruz shertel 15:15:29 also, its not only for new features, 1/2 proposals are for redesigning existing 15:15:45 s/feature/refactor 15:16:39 ok, so post feedback on PR and lets discuss again next meeting if/when ammendmants are done 15:17:41 Needs to have information about how the champion pushes the proposal through these stages (ie: put it on the meeting agenda, anounce to the mailing list, etc) 15:18:42 agreed, but since author is also not here, moving on, post feedback on ticket, lets pick up next meeting 15:18:52 #topic facts/info module standards 15:19:01 #info related proposal https://github.com/ansible/proposals/issues/56 15:19:08 ^ anything new on this topic? 15:19:50 seems we are stuck with several directions, going for _info/other suffix and/or 'autoload' magic seem biggest issues 15:20:55 no comments, so skipping 15:21:05 # module defaults 15:21:15 #topic module defaults 15:21:19 #INFO https://github.com/ansible/ansible/pull/22648 15:21:32 ^ seems its at a good spot, any objections at thsi point? 15:21:53 Needs to pass tests. 15:22:15 mattclay: that is PR side, mostly dealing with concept itself here 15:22:40 approval here never means PR can be merged w/o passing normal requirements 15:23:40 ok, so closing that as community issue and letting PR run its corse 15:24:03 #topic expand documenation fields 15:24:09 #info https://github.com/ansible/proposals/issues/58 15:24:20 ^ made some changes based on feedback from last time, thoughts? 15:24:37 bcoca: just the question about combine hash (for module defaults) 15:25:04 abadger1999: is that on the concept or is that better expressed as part of PR review? 15:25:06 bcoca: don't close the issue yet... otherwise we'll likely forget that we're supposed to be reviewing the PR. 15:25:34 abadger1999: i doubt it, big enough feature and author is not the quiet type 15:27:42 I guess that's pointing back at us needing a way to track PRs from the community to make sure they don't fall off the radar. 15:27:46 if we don't have validation on the types, i don't see why this is necessary 15:28:08 are we going to allow module args to assert "list of strings" for example? 15:28:19 jtanner: we can, that is part of subspec 15:28:23 ^ related but diff PR 15:29:00 also, loose example, does not need to be exactly as i printed, so this is good point of discussion 15:29:05 makes me feel like we're turning into java 15:29:06 we can force 'exact types' 15:29:18 bcoca: Did we decide that hte module defaults should use combine_vars? 15:29:22 jtanner: docs are there to inform user what he can input 15:29:49 abadger1999: not that i know of, but i dont think that is for this meeting, but discussion on PR, its implementation detail 15:30:02 bcoca: combine_vars is design. 15:30:27 It could use it or it could not use it... doesn't change the code much but changes how users interact with it. 15:31:58 abadger1999: not sure it makes much sense that users can override merge for overwrite ... the latter just disables the functionality with unrelated config setting 15:32:34 in your view, for module_defaults to work, hash_behaviour = merge must be configured? 15:32:48 instead of = replace, which is the default? 15:32:49 bcoca: #undo 15:32:53 #undo 15:32:53 Removing item from minutes: INFO by bcoca at 15:24:09 : https://github.com/ansible/proposals/issues/58 15:32:59 bcoca#undo 15:33:04 #undo 15:33:04 Removing item from minutes: 15:33:05 #undo 15:33:05 Removing item from minutes: INFO by bcoca at 15:21:19 : https://github.com/ansible/ansible/pull/22648 15:33:15 #info https://github.com/ansible/ansible/pull/22648 15:33:24 bcoca: I don't know. 15:33:53 bcoca: I'm throwing it out there because I don't know what the right thing is in this case but think that we should make a conscious decision about it. 15:33:54 i dont think it should 15:34:41 the feature is clearly to 'merge defaults', having hard override is 'disabling defaults' ... seems like the hash_behaviour should NOT control this feature as they are pretty much unrelated 15:34:55 bcoca: ah.... I mean when we have defaults defined in multiple places. 15:34:58 same way with do with tags/conditional inheritance, they are always merges 15:35:47 abadger1999: keyword merge/override is something we do differently depending on keywords (tags vs name, for example) 15:36:23 ^ i would not make it subject to hash_behaviour, i'm fine with switching between merge and replace, but im not sure which one makes more sense 15:37:47 bcoca: okay. How do users get rid of a default (say in inventory I defined a default for yum enablrepo; in a specific play I want to get rid of that default) 15:38:08 default=omit 15:38:51 agaffney: ^ your input? 15:39:27 Is that a sentinel value? 15:39:53 whateverfield={{omit}} <= would merge/override parent def, then on templating be removed 15:40:15 Okay. 15:40:37 ah, think agaffney is traveling today, so we can reschedule for next week to finish this 15:40:53 So We're thinking, use merge_hash() (not combine_vars) always. Document that whateverfield: "{{ omit }}" can be used to remove a default value 15:40:56 abadger1999: add to PR so he is aware of the usability 15:41:18 If that's correc, I'll add that to the PR 15:41:18 I kind of like the idea in action (ie, it seems useful) but I'm a little hesitant of possibly introducing another inheritance mechanism 15:41:41 alikins: it follows existing ones 15:42:24 abadger1999: just dont think combine_vars is way to go as it changes depending on diff setting, merge vs replace is the 'usability discussion' on how this should be inherited 15:42:32 _get_module_defaults() looks like new code to me 15:42:51 ^ i think merge is right way, even if we end up doing replace, it should not be implemented via combine vars 15:43:08 Yeah, I'm fine with that.. just want to make sure we're in agreement about what we want it to look like before I tell agaffney what we want. 15:43:10 alikins: it mirrors what we do already for others 15:43:32 abadger1999: dont think we need agreement for that, to explore the use cases in ticket 15:43:48 if we phrase as question vs mandate 15:45:03 alikins: in diff discussions, i think we can better streamline how inheritence works to make it more automatic vs forcing explicit like we do here, but htat is outside scope of the ticket and something i was planning on brining up once jimi-c is back 15:46:42 abadger1999: i think we all agree on basic feature now, details like how this should be inhertied can be hashed out outside this meeting, otherwise I think we can take up the time by going too in depth to these topics which can be handled in the ticet/review 15:47:28 if we are all ok with the basic functionality, i would move on and deal with this topic on the PR review from now on 15:49:42 ok, so moving on, back to documentation expansion 15:50:00 #topic expand documenation fields 15:50:02 We can move on but the problem with only using hte PR for review is that we don't all look at the PR. 15:50:06 ^ i updated proposal with subspec ref 15:50:22 #chair alikins 15:50:22 Current chairs: abadger1999 alikins bcoca jtanner mattclay nitzmahone rcarrillocruz shertel 15:50:31 so if there's other things of design improtance, it should come back to the meeting then. 15:50:51 #info https://github.com/ansible/proposals/issues/58 15:51:21 abadger1999: ok, but we should set a threshold or just discuss adhoc, this meeting gets overloaded easily and I would like to keep stuff at higher level 15:51:31 ^ on open floor lets discuss scope of this meeting 15:52:04 abadger1999: also even if merged, does not mean we keep the feature or it cannot change while in devel 15:53:02 Expanded doc options are much clearer now... +1 15:53:31 (putting config/env under options makes a lot more sense to me now) 15:53:31 i can see us still modifying them, but i think it now captures most of the utility 15:54:04 Thanks for clarifications, bcoca! 15:54:09 nitzmahone: yeah, for those that 'dont have options' i just used _ to denote 'internal name', must make sure we document that somethwere 15:54:59 we've been 'kindof' using it, but never offiically stated that it is so in docs, though most people seem to infer correctly (i've still seen people do shell: _raw="" ) though 15:55:24 Yeah, and "_free_form"... 15:55:39 ^ he, same 15:56:00 bcoca: When multiple names are given, should all but one be deprecated? 15:56:02 not cause i think someone will read, but we can have something to point at 15:56:16 abadger1999: no, in case of ec2, for example they are all still valid 15:56:26 (sigh) 15:56:29 bcoca: what's the ec2 case? 15:56:33 i HOPE that internally we do follow that rules 15:56:34 doc fields pr looks good to me. I'd go for maybe 'type_description' or 'arg_description' vs 'type' though 15:56:48 " AWS access key. If not set then the value of the AWS_ACCESS_KEY_ID, AWS_ACCESS_KEY or EC2_ACCESS_KEY environment" 15:57:03 k 15:57:19 I think we should say something about precedence then... 15:57:28 Is there a free-form field? it could go in there. 15:57:37 abadger1999: i looked at existing stuff, its not everywhere, but happens enough that we need to cover, specially with cloud modules 15:57:39 Yeah, it's weird like that for the libcloud-based stuff too IIRC 15:57:46 I don't need a formal field, just want it to be documented 15:58:02 abadger1999: i thought about 'priority' : 15:58:34 but ssh is maybe bad example, was thinking that ansible_host == all connection plugins, might require diff docs 15:58:52 then document only specific in ssh, but i left it there as example 15:59:22 (note: precedence of config/env_vars/hostvars should be covered in our general doc, I jsut want a place to put precedence of multiple env_vars, or multiple config values. 15:59:27 ^ still unsure if we should just repeat in every plugin or document the 'base' on one side and teh specifics in each plugin 15:59:52 abadger1999: understood, yes, that was what prioirty was for ( i did put it in last night, but thought it was too confusing so i removed) 16:00:14 bcoca: something like extends_documentation.... ie: one file but rendered on multiple pages. 16:00:24 ^ we also have 'multple config settings' case in 2.3 (just removed in 2.4) 16:00:43 Yeah, priority: could definitely be confusing. 16:01:03 abadger1999: we already have fragments (it works, tested), but i was thinking of 'connection base page' then list plugins, base having common vars 16:01:21 to people who don't understand that config/env vars/hostvars are already prioritized. 16:01:56 abadger1999: i even thought that implicit 'top less priority, bottom more' in the listing would be enough ... but again, can confuse people 16:02:13 bcoca: I'd keep it all on the specific pages... people are most often going to hit the page for the plugin they're looking for, not a hierarchical set of pages. 16:02:26 good point 16:02:45 so fragments might need 'better merging' so as not to duplicate too much data 16:03:06 yeah. Or we be better about organizing nad splitting the fragments. 16:03:50 so it seems we all mostly agree on adding fields, mostly its a question of details now? 16:04:17 ^ please add those thoughts to ticket and we can carry on detailed discussion there, revisit here once we've gotten to something a bit more flushed out 16:05:04 Instead of " lookup: etcd" I'd do: "type: lookup\nname: etcd" 16:05:36 abadger1999: followed the current 'module: ' pattern 16:05:42 ^ would need to change it there also 16:06:06 bcoca: probably should with the current way being deprecated backward compat for now 16:06:30 i'll see what i can do, that might get tricky 16:06:52 since modules was the only thing using the module documentation format, it's going to have a few things that are not right for multiple plugin type. 16:06:59 as the format is same in 'both ways' internally, just the 'location' of the docs is different 'varaibles vs 1st docstring' 16:07:05 I don't think we need to solve finding a general way to indicate precendence of env vars just for docs, so I wouldn't worry about that atm 16:07:34 alikins: not just env vars, config settings also (we only had 1 and i removed it, but i expect more in future) 16:07:42 and of course host_vars ... 16:07:56 which we have MANY cases of 16:08:21 I'd change the algo to be Look for 'type: XXX" and "name: YYY" if both do not exist, look for "module: name" and fill in type/name with values from there. 16:08:51 i'm going to move on, as these are smaller details we can deal with in the ticket and revisit it for approval next meeting 16:08:52 *fill in missing value 16:08:55 16:09:35 #topic core/extras ticket migration 16:09:46 https://github.com/ansible/community/issues/156#issuecomment-288205452 <- from last week, @jctanner brought up 16:10:56 jtanner: any updates? 16:11:06 Did we only end up with my -1 on #1? I thought jctanner was also -1. 16:11:24 i counted you as +1 .... 16:11:40 would mean it was tie? 16:11:44 I was +1 on #2 16:11:54 asking me if there are any updates, implies to me that i'm on the hook for figuring it out 16:12:09 thought all 4 of us were +1 on 1 and 2, except jtanner which was -1 on 1 16:12:11 I didn't vote last time, but I'm leaning towards -1 on #1 currently. 16:12:12 jctanner abstained. 16:12:18 nitzmahone was -1 16:12:22 so i've gone off and done some of my own work to look for duplicates and make sure what should be migrated has been done so properly 16:12:30 jtanner: no, sorry, assumed you were doing this via bot 16:12:49 the bot has hooks to begin the process 16:12:55 but it's waiting to be told what the process is 16:13:55 well, #2 seems clear, #1 i though had majority, but it seems i was wrong 16:14:20 nitzmahone, abadger1999, jtanner any position change on #1 since last meeting? 16:14:43 ^ anyone else want to weigh in? 16:14:51 @here 16:15:37 Are those proposals mutually exclusive? 16:15:43 Seems as though they are not 16:15:43 No 16:15:47 no 16:15:56 issues vs prs 16:16:01 i will have to patch the bot to "pretend" the original submitter is the owner of the issue, if the bot is doing the migration 16:16:03 #1 deasl with issues (not prs) 16:16:06 it's doable, but still a headache 16:16:08 Ok, I suppose the fact that they were listed like that made them seem as though someone intended them to be exclusive 16:16:11 #2 deals with PRs and not issues 16:16:25 and the bot will need to give the original submitter a bunch of commands to be able to edit their own issue ... more headache 16:16:32 sivel: if you can list them so that is not inferred, go ahead 16:16:45 I missed that distinction the first time around too. :) 16:16:47 just getting clarification. 16:16:52 bcoca: I've updated thvote i nthe comment with the actual counts (and names). 16:17:04 I am +1 on #2 16:17:10 (for modules that consult env vars, it may be useful to be able to indicate that in the arg spec, possibly including precedence. That could eliminate alot of boilerplate (some_arg_value = module.params.get('some_arg_name', None); if not some_arg_value: some_arg_value = os.environ('SOME_ARG_NAME') etc) 16:17:29 alikins: we've moved on 16:17:32 abadger1999: i did not remember that many votiing .. thankx 16:17:33 I feel like I am -1 on #1, but could probably be convinced to change 16:17:58 alikins: we built that in already for network modules, iirc 16:18:30 #chair sivel 16:18:30 Current chairs: abadger1999 alikins bcoca jtanner mattclay nitzmahone rcarrillocruz shertel sivel 16:18:47 ok, so #1 has slight majority ... do we want to wait for jimi-c to tie break? 16:19:01 or fully tie .... 16:19:03 jtanner: note, it does not need to give them more commands. for issues... what is important that the owner can do that a commenter cannot? 16:19:23 abadger1999: closing 16:19:42 bcoca: I think with my vote we are tied 16:19:52 abadger1999: set ansible version, change title, etc 16:19:54 changing updateing title/original post , but that matters less 16:19:55 bcoca: usually if something is very close, I try to get more people to weigh in so that it becomes more clear that it wasn't decided this way just because only certain people were present. 16:20:10 jtanner: I don't think ansible version and change title are too important. 16:20:15 bcoca: do you want me to add my vote to the comment? 16:20:17 sivel: added yoru vote 16:20:19 nice to have but far from essential. 16:20:22 k 16:20:31 closing is very nice as it offloads work for us. 16:21:19 Content is not lost, and can theoretically be migrated at any time 16:21:22 ok, so it seems we have tie on #1, #2 all agree, any new arguments for/against #1? 16:21:38 But keeps a bunch of ownerless issues out of the repo 16:21:55 Did my -1 vote for #1 get counted? 16:22:20 now it is, total -1 16:23:07 so alternates to #1 were : a) let them rot or b) include them in weekly backlog 16:23:10 what is the perception of what will happen to the issues once they are migrated? 16:23:22 jtanner: they become part of weekly backlog 16:23:36 if we let them rot, that is effectively closing them. No one will look at them 16:23:36 (a) is a bad thing. (b) is also a bad thing. 16:23:37 ^ well daily, but we do every 2 weeks personally 16:23:47 (c) close them 16:23:49 I say, follow something similar to #2 for issues 16:23:57 abadger1999: waiting for 'good thing' .. c) is also bad 16:23:58 community supported modules are part of the backlog for us? 16:24:06 ^ thought most had agreed that c) was not option 16:24:19 jtanner: no, but some might be 16:24:31 ok, some ... and what about all the others? 16:24:35 They should be reviewed as part of a backlog review, or closed. However, I don't see why they can't be reviewed where they are. 16:24:36 what happens with those issues? 16:24:36 not all tickets are for community (well extras mostly is) 16:24:49 Why should we treat them differenty? Update all issues saying if they aren't migrated, they'll be closed 16:24:50 jtanner: same as what happens to current community tickets in ansible/ansible 16:24:51 (a) is bad because people think they are being looked at but htey aren't (b) is bad because, a salikins said, issues should live with the code. (c) is bad because we've already done this to people once. 16:25:33 if (d) is off the table now (move issues to ansible/ansible) then I'm a reluctant advocate for (c). 16:25:43 I am +1 for c 16:25:48 it's the least bad choice remaining. 16:25:58 but not just blindly close, update them asking people to move them again, then close 16:26:11 they should also validate whether they are still issues 16:26:29 and most of them are probably never going to do that 16:26:36 that is too much work for us to take on, put the onus on the requester 16:26:41 that is a good thing then :) 16:26:46 the ones that have and care about it, have mostly migrated all their issues 16:26:52 if they don't they are closed, and we have less issues 16:26:53 Regardless of which repo they're in, someone needs to review them. Moving them when they haven't been reviewed seems like wasted effort. 16:27:18 agreed 16:27:27 but we don't have the time to do it ourselves 16:27:29 mattclay: it's inconvenient to have them in another repo... harder for us to spot duplicates by searching, not as easy to associate issues with commits and PRs, etc. 16:27:34 i closed 5 last meeting in quick review, i propose to make next month 'backlog review' to go on core/extras and close as many as we can 16:27:38 mattclay: that's why i'm asking what people believe is going to happen to all those issues after i spend a week or two getting them migrated 16:28:11 jtanner: i dont think a week of your time is worth it for migration 16:28:28 ^ thought we already had automated process 16:28:28 auto-migration is going to require supervision 16:28:36 it will take a week or more to get it right 16:28:46 hmm, -1 then 16:29:02 are we collecting votes for this? 16:29:03 actually ... 0 16:29:13 i dont konw which option sucks less 16:29:18 I would be less opposed to review then migrate vs. migrate then review. 16:29:23 there's rate limits to deal with, bad issue bodies to deal with, new code to write for the bot to "pretend" original submitter is still the submitter, etc 16:29:29 sivel: not yet...someone needs to make a proposal (instead of the three mutually exclusive ones that we have now) 16:29:39 abadger1999: ok 16:29:49 I liked your a, b, c, d :) 16:29:56 well, c personally 16:30:00 sivel: go ahead and propose, though.. I think we're tapped out on discussion. 16:30:27 updated ticket to reflect subject better 16:30:57 a) Leave them as they are, maybe looking at them 16:31:10 b) Add time to every meeting to go through some of them 16:31:22 c) update them asking people to migrate them, closing after a period 16:31:29 sivel: b) which meeting? 16:31:30 d) Just migrate them and deal with it later 16:32:08 bcoca: which ever, this one? Create a new meeting? That gives us a defined time for a bunch of people to look at them 16:32:15 sivel: migration would 'auto include them' into our current workflow of ansible/asnible, which implies backlog review and others 16:32:30 Perhaps we shouldn't treat all issues in core/extras equally. For example, there are 237 feature ideas in core. Do we really want to keep any of those issues? 16:32:48 d +1; c +1 (ok with period being 0 too... we've already commented once) [preference is still d but c is ok] 16:32:50 sivel: added option 16:33:08 mattclay: mostly, even if we don't implement, someone else might 16:33:11 I am +1 for c 16:33:14 mattclay: that's a larger question ... why do we keep any feature_requests open? 16:33:22 feature ideas are not something we should close unless we really are against them 16:33:51 jtanner: they are 'wishlists' and shoudl not count agianst us as 'bug tickets' 16:33:53 (-1 a -1 b) 16:33:55 +1 for c 16:34:07 ideally, we would be sourcing those for our roadmap ... but we completely ignore them for the most part 16:34:42 jtanner: as a group, yes, i routinely go over them to see if we already imlemented or can now easily do so 16:34:49 honestly in a project as large as ansible, feature requests are largely useless 16:34:51 bcoca: How often do feature request tickets actually get acted on? It's a nice idea in theory, but if it isn't actually getting us anything, it's not useful to keep them around. 16:34:55 ^ closed 3 last week (2 were mine ...) 16:35:00 sivel: i agree 16:35:01 +1 for c 16:35:11 jtanner, sivel: +1 16:35:21 so far we have +4 for c 16:35:48 again, I think they should be handled the same was as the PRs 16:36:33 which is the same way we handled repo split :-( 16:36:44 not exactly 16:36:52 we just closed immediately 16:37:00 and didn't offer advice on moving them 16:37:33 mattclay: the other reason, i keep closing dupes for same feature 16:37:34 I'd guess the majority of issues, were submitted by someone who doesn't care any more 16:37:52 drive bys 16:38:01 but if we give them a 2nd notification, we can help determine that 16:38:03 or frustrated 16:38:36 migrated once from ansible/ansible to ansible-modules-core... refuses to migrate a second time back to ansible/ansible 16:38:38 no doubt many people get frustrated, but that is regardless of a repo merge 16:38:51 it doesnt help 16:38:58 if they are issue sthat old, we largely don't care about them either 16:39:06 as evidenced by their age 16:39:07 many of them thought the issue tracker was a technical support queue 16:39:56 those we close fast in triage, fine with closgin those if there are any in the core/extras, but that requires 'looking' 16:40:01 sivel: not true really... jctanner's dupe finding brought some old bugs onto my radar yesterday... I put up PRs to fix two of them. 16:40:08 It's really about who is responsible for expending effort on these old issues. Is it the original submitter or us? Although it's an inconvenience to the original submitter, having them migrate the issues scales better than having us do it. 16:40:23 mattclay: ++ 16:40:28 mattclay: -- 16:40:32 :) 16:40:42 mattclay: in the case of community modules, it extends to "who is going to do somethign with it?" 16:40:56 mattclay: no question on efficient, the problem is we already take too long to deal with stuff and have mass closed on one migration 16:41:00 ^ feelings involved 16:41:03 mattclay: Expending effort is in reviewing the issues. Migrating is a relatively small amount of effort. 16:41:06 abadger1999: I do understand your point of this being a repeat of what we did with the repo split. 16:41:43 Anyhow... we have +1:4 and noone against.... shall we call closing the agreed solution? 16:41:58 at this point i'm goign to stop discussion, prposals and some votes are in ticket, think we need jimi-c at least if not community guys also to decide how to go forward 16:42:15 abadger1999: So then it's a comparison of review effort in place vs review effort in ansible/ansible + migration effort? 16:42:24 abadger1999: there is one -1 16:42:44 bcoca: is -1 on everything ;) 16:42:51 mattclay: that is one of the options 16:42:54 sivel: im not 16:43:11 2 options im not -1 on 16:43:31 bcoca: who's -1 to (c)? 16:43:48 https://github.com/ansible/community/issues/156#issuecomment-288205452 16:43:49 bcoca is 16:43:54 lost track on what is what 16:43:59 ^ votes there as they were made 16:44:25 all of them have already been notified 16:44:36 the proposal should clarify re-notifiy 16:44:48 "close after automated notice to migrate" 16:45:01 ^ shoudl i add "notices" 16:45:05 which means i can close now ... because they're already notified 16:45:21 ah, I thought you were -1'ing Proposal 1 from last meeting after jtanner's explanation of the work he thought that involved. 16:45:21 last discussion implied they should be notified again 16:45:41 added 'new' there, jtanner does that disambiguate enough 16:45:42