19:01:31 #startmeeting Ansible Core Team 19:01:31 Meeting started Tue Mar 14 19:01:31 2017 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:01:31 The meeting name has been set to 'ansible_core_team' 19:01:38 * thaumos waves 19:01:39 abadger1999: beat me too it 19:02:10 #chair gundalow bcoca thaumos dag funzo rcarrillocruz ryansb nitzmahone alikins jtanner mattclay Qalthos shertel 19:02:10 Current chairs: Qalthos abadger1999 alikins bcoca dag funzo gundalow jtanner mattclay nitzmahone rcarrillocruz ryansb shertel thaumos 19:02:15 boop 19:02:19 hi 19:02:21 If I'm missing someone, just speak up :-) 19:02:27 hi 19:02:29 hi 19:02:32 borp 19:02:34 gundalow: Happy to let you take it from here? ;-) 19:02:42 hullo 19:02:44 gorrdam it, i fell for that 19:02:47 :P 19:02:54 abadger1999: should we do the thing from Slack last? 19:03:01 * mattclay waves 19:03:03 I see that taking up all available time otehrwise 19:03:24 gundalow: as long as it does get talked about today, yes. 19:03:31 #info Agenda https://github.com/ansible/community/issues/156 19:03:58 #topic How should paths work? 22546 19:04:14 #info default to paths being relative to ansible.cfg https://github.com/ansible/ansible/pull/22546 19:04:17 bcoca: ^ 19:04:54 #info proposed fix for Ansible callback_plugins configuration is relative to cwd instead of config file https://github.com/ansible/ansible/issues/22533 19:05:25 i think we need to go over all path options and decide which are relative to config, which to cwd/when ansible evaulates it 19:05:47 Maybe add tests and document it 19:06:05 tests are there 19:06:19 just had to change them as they tested 'what was happening' not what was intended 19:06:22 ah, didn't scroll down, cool 19:06:24 :) 19:06:39 which makes the test a reflection, not really useful for intent 19:07:34 -1 to relative to config file. 19:07:53 especially with bcoca's feature to merge config files, config file path is not a good measure. 19:08:26 abadger1999: i would argue the contrary in that case 19:08:41 also, this is for current asnible.cfg, which is not mergable 19:09:23 making it relative to ansible.cfg makes it predictable, making it cwd makes it unpredictable for a git checkout 19:09:31 bcoca: doesn't make sense to change it and then change it back. 19:09:35 things liek ssh key file are an exception as that is normally 'user based' 19:09:38 I don't argue that cwd is good. 19:09:45 I just argue that ansible.cfg is also bad. 19:09:47 abadger1999: not saying changing back either 19:10:06 abadger1999: then what? we dont know play dir most of the time these get resolved 19:10:15 ansible.cfg is not predictable in the face of merging. 19:10:56 https://gist.github.com/bcoca/03a05c5fdc7cd652a8e72f38684345c9 <= current list 19:11:13 abadger1999: not sure how that is the case as we know both locations and which one has the setting 19:11:15 bcoca: If playbook is the most reasonable thing from an outside POV, then we have to rework the code to expand relative dirs when play dir is available. 19:11:39 bcoca: is it the most reasonable thing? 19:11:40 abadger1999: hard to do in some cases when we resolve these BEFORE we have a play 19:11:57 bcoca: but from an outside POV, is it the best thing to resolve to? 19:12:26 well, for stuff liek path lists, i would argue, config makes more sense 19:13:18 bcoca: you wouldn't expect that creating a ~/ansible.cfg just to set pipelining=False would make your custom callback plugins no longer findable.... that's why I consider config file location to be wrong. 19:13:50 abadger1999: im not parsing that nor how those are related 19:14:08 could do something support $PLAYBOOK/$CONFIG/$CWD in path values to make it more explicit 19:14:09 etting pipelining will not affect plugins 19:15:18 /etc/ansible/ansible.cfg has a setting for callback directory that's a relative path... that would get resovled to /etc/ansible/callback_dir now I create an ansible.cfg.... suddenly, I can't access my callback plugins from /etc/ansible/callback_dir because the config path changed. 19:15:32 *now I create an ~/ansible.cfg 19:15:54 that is independant of this conversation, since new ansible.cfg will override all settings 19:16:05 bcoca: not once you add mergable configs. 19:16:28 abadger1999: forget mergable configs, we might not do them at all if ansible-pkgmgr is off the table 19:16:41 and IF mergable, they would follow file in which they were defined in 19:16:54 and ansible.cfg is not mergable, nor was planning on it ever being mergable 19:17:29 bcoca: that wouldn't work either because the only advantage of relative paths over absolute is that they can change in context without changing the files. 19:18:13 bcoca: ie: I place an ansible.cfg into a subdir. Then I can use the callback plugins from that subdir instead of from /etc/ansible. 19:18:18 abadger1999: which is mostly used for 'project chekcouts', which do want a predictable path 19:19:37 most people would expect that ansible.cfg in their project checkout points to the ./cback_plugins dir relative to the file, not the one in /var/tmp which happens to be my cwd 19:19:53 bcoca: anyhow, play dir makes sense to me (but we'll have to do work to figure out how to make that work). relative to config is fraught with cornercases that are not intuitive. -1 19:20:33 abadger1999: DEFAULT_FACT_PATH for example doesnt make sense either way 19:20:43 bcoca: no... the /etc/ansible/ansible.cfg has the relative paths. 19:21:01 abadger1999: you canont have 2 config files active at same time 19:21:06 period 19:21:28 bcoca: I was typing that out before you wanted to ignore mergable config ever being a thing. 19:21:51 im discussing current state, not a state that might never be 19:21:55 which still seems like a good idea whether or not we have an ansible installer. 19:22:12 So anyhow -1 19:23:02 https://gist.github.com/alikins/8ea270e21fa233159bc4b1c477d674ee ($PLAYBOOK/ sketch). The various defaults still need to be decided 19:23:59 the other issue with playbook_dir .. it changes in the middle of the run 19:24:10 alikins: whatsi root? 19:24:10 relative DEFAULT_FACT_PATH should not be expanded.... that's something that needs to be expanded on the remote machine. 19:24:19 abadger1999: agreed 19:24:20 bcoca: / 19:24:29 abadger1999: that is why im saying we need to go over EACH option 19:24:43 alikins: then its not relative they should jsut put full path 19:25:51 ^ i do like the idea of CWD/CONFIG/PLAYBOOK, the problem is that PLAYBOOK varies in many cases AFTER we use the config entry 19:26:24 ROLES_PATH? 19:26:29 isnt' that the setting you are setting? 19:28:32 bcoca: read the comment above it 19:28:47 agree with comment .... 19:29:16 CHAIRING: OK, that's almost 30 minutes, do we want to continue, we wanted to allocate some time to the ANSIBLE_METADATA 19:29:31 cwd/config seems easy to implement, that is what expand_relative_paths=False|true basically controls 19:29:39 I think I've seen some tools use psuedo uris for similar cases (ie, config_file:///callbacks/blippy, playbook_dir:///stuff/) 19:29:50 gundalow: we have other items before that 19:30:20 bcoca: another of yours, yup :) 19:30:31 gundalow: I will do almost anything if it means avoiding talking about ansible_metadata 19:30:33 and others 19:30:52 erhamgurd, murtadurta 19:30:56 alikins: but what do we do with those not specified? 19:31:13 We need to move on. 19:31:47 Since we have another one before metadata and metadata is blocking stuff we need to get some sort of resolution for it. 19:31:53 #action bcoca to update 22546 with notes so far from discussion. 19:32:02 this is same, we have conflicting bugs on this 19:32:31 OK, so I can see 19:32:32 gundalow: inconclusion? 19:32:53 bcoca: I didn't want to say conclusions, as I wasn't sure we arrived at any :) 19:32:57 OK, so on the agenda we have 19:33:04 1) Proposal: Module Rename Lifecycle 19:33:16 2) versioned docs - No update, so skipping 19:33:33 3) RST - Approved 19:33:35 1) <= this basically reflects 'current norms' so not really a change 19:33:44 4) do we call them directives, attributes, keywords, etc? 19:33:55 3) was also already norm, we just never did the work 19:34:07 ryansb: So we have anyting else to talk about on " Module Rename Lifecycle" 19:34:13 4: Don't care, docs pick one and let us know so we can try to do it right. 19:34:52 4 same, we just need 1, he jsut have many names all over the place 19:35:01 ok, lets do (4) 19:35:04 2: I added a bunch of comments after the last meeting. So there should be stuff for docs to sink their teeth into to refine it now. 19:35:31 OK, what should we #topic from that list 19:35:56 (4) 19:36:08 #topic do we call them directives, attributes, keywords, etc? ansible/ansible#22524 19:36:26 #info https://github.com/ansible/ansible/pull/22524 Doc directives 19:36:38 Choices: 19:36:40 A) directives 19:36:50 B) attributes 19:36:54 gundalow: no, just holding it until 2.4 & collecting a list to rename 19:36:56 C) keywords 19:37:00 ryansb: Thanks 19:37:37 ^ iirc we probably have another 2-3 ways we refere to them in docs, but those are the ones i remembered off top of head 19:37:47 i belive we also use 'commands' 19:37:52 and keys 19:38:46 -1 commands 19:39:30 C for me 19:39:40 -1 attributes, fine with A or C 19:40:16 "Task Directives" "Task Keywords", they both "sound" right 19:40:32 anyone got a preference between A or C 19:40:39 C 19:40:42 C 19:40:50 #agreed "keywords" 19:40:50 C 19:40:54 woot 19:41:12 make it so :-) 19:41:13 so we have 48+ refs as directive, 29 as keyword, 31 as attribute 19:41:19 if it's a bad idea to use the string as a varname, it's a "keyword" to me 19:42:11 jtanner: 2.3 now warns when you do that 19:43:10 that's nice, still a keyword =P 19:43:20 ok, so metadata next? 19:43:30 erhmagurd, murtadurta 19:43:46 yes, no maybe so? 19:43:56 i have no agenda items 19:44:00 cool 19:44:00 yes 19:44:14 the bot is slowly coming back online after recent meta changes 19:44:22 abadger1999: Can you please set a sensible #topic 19:44:48 "erhmagurd, murtadurta" not sensible enough? 19:44:53 #topic What should be expected from "curated" ? 19:45:38 So couple questiosn here: (1) When does core get involved in reviewing? When PR's are raised or after maintainers have marked them shipit? 19:45:54 (2) Who gets pinged when a PR is raised against a curated module? 19:45:59 or an issue 19:46:22 issues are whoever is maintaining the module... if it's orphaned, no one gets pinged. 19:46:28 true 19:47:02 i suppose i was going down that angle because until we have made "orphan" a thing, we probably shouldn't have curated+nomaintainer 19:47:18 but that's just my opinion 19:47:48 do we have a short list of what is curated+nomaintainer right now? 19:47:56 we probably need to make "doing something real with orphan" more of a priority. 19:48:06 thaumos: there aren't any now =P 19:48:24 #info We need to make "doing something real with orphan" more of a priority. 19:48:28 i would argue curated is not related to mainter status 19:48:39 as orphans are a reality... we just aren't acknowledging them properly. 19:48:44 always meant it as a lightweight gatekeeper 19:48:46 I would argue that it is not a curated module if it has no maintainer. 19:48:55 thaumos: yes, that is my logic too 19:49:12 so goes to community, what happens once it gets a mainainer? 19:49:25 do we recurate? cause we wanted a say on it to begin with 19:49:27 maintainer get's pinged for bugfix + reviews 19:49:31 then it has to go through the motions again to be "graduated" once more. 19:49:49 then its not 'curated' 19:49:55 not sure what to call that state 19:50:07 curation does not involve authorship 19:50:07 sorry confused. 19:50:11 nor maintenance 19:50:20 brb, i broke the seal 19:50:28 curated state then looses most meaning when you tie those into it 19:51:00 who are you responding to @bcoca, me or @jtanner? 19:51:08 both 19:51:17 I had a feeling you'd say that. 19:51:25 actually, all 3 19:51:55 If a module is classified as curated, I feel it should meet a certain criteria. 19:52:40 curation is more about our intereset in the module and it's stability than about module quality 19:52:49 ^ if not, its not curation .. not sure what to call that 19:53:01 1. an active maintainer, 2. tests (eventually), 3. must pass our review process for inclusion. 19:53:09 core is also not reflection on module quality nor stability, just our commitment to it 19:53:21 2+ maintainers 19:53:24 Agreed on interest. 19:53:35 because we're not just going to let any module be a curated module 19:53:56 then lets remove all curated, most dont pass that 19:54:04 for instance, honeybadger_deployment will never be curated. 19:54:11 if that is the meaning, we should have 0 curated 19:54:17 That makes it sound like a privilege to be curated 19:54:23 its not 19:54:29 okay, we're going to an extreme now.... some are unfortunately grandfathered 19:54:29 * abadger1999 agrees with bcoca's statement that most current curated don't pass that bar. 19:54:31 its a burden 19:54:41 both to us and the community 19:54:45 that def makes no sense to me 19:54:51 I agree that all curated are not passing that. 19:54:58 what makes no sense? 19:54:58 might as well not have it (hears abadger1999 cheer) 19:55:46 bcoca: if you wait long enough, you should hear it again after it passes around the world and comes back again ;-) 19:56:26 If i'm allowed to make a succession, make only 2 types of Modules, the stuff thats in the repo is commited by the dev team and gets supported, all other stuff should not be in the repo :-) because it gets partialy maintaned, maybe make something like a Module Galaxy :-) 19:56:33 at this point i question why have metadata at all, it certainly does not seem to deal with the problems it was initially prposed for 19:56:55 @daBONDi, that's definitely a longer term discussion. 19:56:58 daBONDi: metadata was a 'transition' to that since we cannot just remove those modules 19:57:08 daBONDi: That's the long-term plan.. we've been having other discussions how to get there in a timely fashion. 19:57:13 make 'expectations' clear on what we support, what we need to be involved in, what we dont 19:57:30 but ... clearly we cannot agree on this at all 19:57:57 It's because we all have different definitions on words and how words are overloaded. 19:58:36 i currenlty dont find metadata useful at all, quite the contrary 19:58:49 why not? 19:58:50 To be clear, what problems are we trying to solve by having "curated", instead of just "core" and "community"? Or rather, what problems do we have in all "curated" modules were "community" instead? 19:59:00 * jtanner only uses it to determine if community can shipit or not 19:59:17 other than that, it's noise to me 19:59:26 mattclay: modules we cannot commit to maintaining but we want to supervise to ensure changes dont traumatize users 19:59:53 jtanner: for me curate/community only big diff is automerge vs not 20:01:02 curated should not allow automerge, so if that means no shipit, then no shipit 20:01:11 pretty much 20:01:15 shipit or no shipit 20:01:18 thaumos: no, shipit means 'core can review as community approves' 20:01:25 thaumos: automerge does not have 'shipit' .. its merged 20:01:41 but that's the goal, is it not? 20:01:51 it's the current state 20:01:57 minus the merge not actually happening 20:01:58 well, current state there is no automerge 20:02:17 curated='mark as shipit instead of automerge' 20:02:22 community=automerge 20:02:25 automerge or not is the only encoded-in-code difference I can think of... we have two other sets of differences "workflow" (I think the questoins I brought up belong in there) and definition (bcoca and thaumos and expressing different ideas of that) 20:02:27 core=no shipt 20:02:33 but the merge is not happening because i've purposefully disabled it till shipit algo is verified ... i think that's good now though 20:02:49 hmm... I wouldn't use shipit as a keyword in curated's case. 20:03:12 because ^ that could make the algorithm harder, right? 20:03:29 also 'shipit' to merge, is currently not happening due to freeze 20:03:35 that too 20:03:47 thaumos: same algo we have now 20:03:51 so maybe i said it wrong earlier 20:04:06 thaumos: so shipit is coming up in relation to workflow -- If the workflow is "PR submitted => Core reviews => merge or reject) there's no shipit keyword. If the workflow is ( "PR submitter" => "Community reviews" => "Core reviews" => merge or reject) then shipit comes between "community review" and "core review" 20:04:07 again, as workflow i always saw the ONLY difference between curated and community is automerge 20:04:08 it's automerge or not automerge ... those are the different results that metadata is driving 20:04:26 curatged woudl be labeled shipit, community would just automerge 20:06:16 ^ having maintainer or not, shoudl not make difference in the category 20:06:47 it's orthogonal? 20:06:53 exactly 20:07:06 because no maintainer means it'll never get to the point of deciding to automerge or not 20:07:07 I think it could be a measure of health but yeah, I can see it being orthogonal. 20:07:28 that was, the original intent .. but then we changed to 'supported_by' and i think that has muddied the waters ever since 20:08:03 automerge: yes|no 20:08:13 so are we all agreeing that "supported" is a bad word? 20:08:18 ^ if that is less contentious +10 20:08:38 thaumos: yes, we all agreed on that, changed it 5 times and ended back at not changing it 20:08:46 thaumos: i think so ... it takes many lawyers to define the word 20:08:52 yeah because we wanted to avoid a version bump 20:08:56 so there's probably a policy question tied in there... maybe we need to look at modules which are curated and unmaintained periodically and decide something else aobut them ("We don't care enough about this module to give it a maintainer, so move it out of curated" "We care enough about this module and no community member is stepping up s o we have to adopt it" "this module is hanging on without too many bugs so we'll continue to let it be 20:08:56 unmaintained for now") 20:09:23 abadger1999, agreed. we do need a policy around those. 20:09:30 abadger1999: i would argue we should do that with or without these categories 20:09:41 from a my personal expirience as a user, i always copied most of the win modules and rename it because the fixes taking to long to get into devel, so this workflow need to be simplified 20:09:51 +1 remove curated, use automerge instead 20:10:03 yeah, but when we get to a point of community being separate, it won't matter for them. 20:10:17 bcoca: in the eventual world, we don't have to do it for things labeled communit as those won't live in our repos or our tarballs. 20:10:21 daBONDi: that is the point, to get to automerge of the community for most modules 20:10:48 abadger1999: that might not happen since ansible-install is now in doubt 20:10:56 ^ w/o it we cannot really migrate them to galaxy 20:10:56 why is it in doubt? 20:11:00 or other exteranl repo 20:11:13 thaumos: cause you and jason just told us 3h ago? 20:11:16 lol 20:11:23 don't worry about that 20:11:42 * bcoca goes to bed and hopes the world will make sense tomorrow 20:11:50 it will never make sense my friend 20:11:59 he's afraid of a pkg mgr 20:12:38 anyways, tangent. we can talk about offline 20:13:22 so how about this, let's regroup here right now, and highlight the problem again. 20:13:56 pkg mgrs are the things of nightmares, we shoudl ALL be afraid 20:14:22 +1 to automerge key 20:14:36 (1) When does core get involved in reviewing? When PR's are raised or after maintainers have marked them shipit? 20:14:36 3:45 PM (2) Who gets pinged when a PR is raised against a curated module? 20:15:29 have we info'd ^ 20:15:29 2) i pose is 'wrong' quesiton, 'who gets pinged when PR is raised against module' <= answer: maintainer, if none, mark as orphan and let issue/pr user know 20:15:51 ^ that workflow should be true not matter any other categorization of module 20:16:12 informing the user is the only thing not being done right now 20:16:21 s/user/submitter 20:16:45 but does that sound right? you wont need any other logic other than 'mantainer exists or not' 20:16:57 ^ folder maintainers included in that 20:17:13 not so many folder maintainers 20:17:19 i know 20:17:29 but its at least 1 level of possible backup 20:17:54 not sure i follow 20:18:07 if docker_network gets a PR, who is pinged? 20:18:15 orphan 20:18:29 though they currently are mislabled as core maintained 20:18:47 they shouldn't have been, imo 20:18:51 proposal from me: (1) Update the metadata docs to define curated as:"The Ansible Core Team is the gatekeeper for this module. The core team will review any PRs that are marked shipit by the community for additional concerns about code quality, consistency, completeness, and potential regressions and then merge if appropriate. They are not on the hook for generating fixes or new features for these modules" 20:19:17 -1, lets just eliminate curated 20:19:23 automerge is better key 20:19:44 this is the current wording of "curated" 20:19:53 https://www.irccloud.com/pastebin/jPJHK3BQ/ 20:19:55 +1 to what bcoca said about docker_network and orphan. 20:20:08 This module is supported mainly by the community and is curated by core committers. <= current wording of curated 20:20:09 if we're updating the definition of curated. 20:20:26 abadger1999: im for just removing the supported_by key 20:20:29 ^ nix it 20:20:32 and we can rename the curated key to automerge with the new defintion as well. 20:20:36 just add automerge key instead 20:20:41 no def needed 20:20:45 bcoca: I'm throwing my hands up in the air right now. 20:20:54 welcome to my world 20:20:57 I think that's too much change. 20:20:58 \o/ 20:21:21 we shouldn't remove the ke 20:21:30 s/ke/key 20:21:30 You want to remove supported_by and put in automerge: yes, no instead? 20:21:44 the current key is counter productive as it transmists confusion and clarifies nothing 20:21:46 Just to make sure I'm not misinterpreting 20:21:55 that's my suggestion too ... but i have more context about what our parent company is going to require of us 20:22:00 hell, i would not add metdata at all, automerge can be kept in maintainers.txt 20:22:12 abadger1999, we're just still fixated and overloading "supported_by" 20:22:21 that's the problem 20:22:24 nope, im outright removing it 20:22:38 we need it there though @bcoca 20:22:51 Sooo..... I think that needs a proposal. 20:22:58 thaumos: eventually, once it does something helpful 20:23:06 We'll need to modify ansible-doc and the files we have in release. 20:23:12 and website generation 20:23:14 ansible-doc does not need modification 20:23:18 bcoca: it does. 20:23:19 ^ website does 20:23:29 abadger1999: why? if metadata is not there, it does nothing 20:23:35 yes, abadger1999 everything needs a proposal... the problem here was we were trying to meet half way with definitions, and we still don't agree on them. 20:24:05 1-800-GET-BDFL 20:24:39 because *cough*certain people*cough* are expecting that ansible-doc will tell the difference between modules supported by ansible, inc and community. removing metadata means we need to get that information from the maintainer.txt file 20:24:58 Is that a real requirement/ 20:25:00 seriously, i don't think we're ever going to agree on terminology related to "support" ... until we're forced to by lawyers/managers 20:25:01 not heard of that before 20:25:24 jtanner: good point, I don't think Engineers should define it either 20:25:29 we need someone to just make a call, end it and move on and let the pieces fall where they will 20:25:29 abadger1999: that is something we were trying to establish, since it seems we cannot, why have it? 20:25:43 well... although that came to me from higher up... i think bcoca was the actual cause of it. 20:25:53 ok let's stop. 20:26:14 If he's okay with wild west modules and not making it obvious which modules are wild west in ansible-doc then who am I to get in the way? 20:26:14 +1 to stopping :) 20:26:15 everyone breathe 20:26:18 i proposed it to establish a clear communication on what expectations we were setting, since we cannot clarify those expectations, wtf are we communicating? 20:26:41 i only triggered the convo earlier because 3 modules were "curated" without maintainers and that seemed extra odd to me ... those are now "fixed", for varying definitions of the word 20:26:59 jtanner: no... you uncovered a bunch that are broken. 20:27:01 ^ which was fair @jtanner 20:27:13 things which are curated or community and have ansible as maintainer. 20:27:45 yes, i believe that to be a problem ... but i don't think we're going to solve it through majority agreement 20:28:11 jtanner: if we move those into community, then I think we'd all agree it's fixed. If you make them orphaned, then I think some of us would agree it's fixed. 20:28:32 we had 2 issues going in that metadata was going to solve a) set expectations, b) enable automerge, since a) we cannot do ourselves, lets just do b) which can be done w/o metadata 20:28:55 yes, "fixed" to us ... but to the people who wanted it "curated" for some misperception, they are now "broken" 20:29:06 hmm... 20:29:19 jtanner: okay... so we labeled it curated. But we did have the list reviewed. 20:29:33 who reviewed it abadger1999? 20:29:50 So I guess we would have to say "We want to label these curated modules community" and then have newtMckerr run it up the flagpole. 20:29:50 because I was just about to propose to do a review 20:29:52 is misperception even a word? i feel like i just made it up 20:29:58 okay, how about this... I will take it on to review the current list of all modules. I will review that list with the leads and jason and we'll take action on them accordingly. 20:30:22 here's the problem with that. ... 20:30:25 yes it is @jtanner 20:30:29 it goes like this ... 20:30:53 "ec2.py is curated, so we want to make it community so that it can grow" 20:31:04 "oh no, we can't break it, we have people depending on it" 20:31:37 "so we're going to resource making it fully supported?" 20:31:39 "no ..." 20:31:48 cloud/amazon/ec2.py is a great example of curated. It should not be community because of your point @jtanner 20:32:04 fully supported == core, and that i don't think is ever the plan 20:32:23 you don't see the issue there? 20:33:24 this impasse is cyclical, lets jsut move passed it 20:33:26 That's the recipe for "These modules are stagnate. But we want to sell that as a good thing!" 20:33:33 anyone against automerge setting in maintainers? 20:33:39 abadger1999: yes, i couldn't type it so eloquently 20:34:04 Here's the issue I see with ec2.py, the core team has become the sole maintainer... however, we've resourced it to 1.5 individuals, and we classified it as curated because of that. Ideally, we will be getting a partner to work on them in the future; which is a wip 20:34:22 abadger1999, jtanner modules stagnate a lot more cause of lack of maintainer than because we reserve final review 20:34:26 bcoca: I'm okay with it but it needs a proposal because there's a fair amount of code to change and stakeholders to get buy in... given that, I'm not sure we can do it for 2.3. 20:34:39 abadger1999: only code that chagnes is ansiblebott 20:34:57 I am against removing it. I am for getting to an agreement on the definition, and proper words. 20:35:09 abadger1999: not talking about metadata at all, now im exclusively proposing an automerge no|yes flag for ansibot 20:35:25 * thaumos retracts statement above 20:35:31 *sigh* 20:35:58 @here, anyone against having an automerge setting on asibot? 20:36:02 asnibullbot 20:36:08 ansibullbot? 20:36:17 if it's doable, why not? 20:36:22 that's the goal, right? 20:36:22 jtanner: ? 20:36:31 bcoca: REason to have a proposal is to gather all the things that have to hcange. We have to remove the usage of metadata from ansible-doc and website generation 20:36:34 if anything, it reduces lines of code to determine automerge 20:36:35 yes, want ot disociate the automerge discussion from others 20:36:39 Probably should remove it from testing as well. 20:36:47 abadger1999: we're not removing metadata 20:36:47 (can remove it from modules at our leisure) 20:36:47 abadger1999: this has NOTHING to do with metadata 20:37:10 Need to get buy in from thaumos and jmckerr... who are proxies for other people within the organization. 20:37:28 which takes time for them to do their work. 20:37:45 These are things that have to be done. You asserting that they don't does not make it so. 20:38:09 I agree what bcoca is suggesting has nothing to do with metadata 20:38:15 I do too. 20:38:21