17:01:49 <gundalow> #startmeeting AnsibleFest Contributors Summit: Community Collections & Community Workflow 17:01:49 <zodbot> Meeting started Mon Sep 23 17:01:49 2019 UTC. 17:01:49 <zodbot> This meeting is logged and archived in a public location. 17:01:49 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:49 <zodbot> The meeting name has been set to 'ansiblefest_contributors_summit:_community_collections_&_community_workflow' 17:02:48 <gundalow> #chair abadger1999 acozine akasurde alikins bcoca dmsimard ganeshrn gregdek jborean93 jillr jimi|ansible jtanner mattclay madonius nitzmahone samccann sdoran 17:02:48 <zodbot> Current chairs: abadger1999 acozine akasurde alikins bcoca dmsimard ganeshrn gregdek gundalow jborean93 jillr jimi|ansible jtanner madonius mattclay nitzmahone samccann sdoran 17:02:59 <gundalow> Anyone one remote here for this? 17:03:18 <abadger1999> Howdy 17:03:31 <jtanner> Hey, I need to juggle this and cloud breakout. Be down there after we finish talking vmware 17:03:34 <felixfontein> gundalow: I'm half-way here and half-way in #ansible-cloud 17:03:36 <rharolde> listening, all is quiet 17:03:41 <felixfontein> no idea which one will be more relevant for me :) 17:04:00 <gundalow> Yup, I think people will bounce between a bit 17:04:18 <abadger1999> I'm not sure where I'm needed either. So I'm here but if someone wants me somewhere else, they can pull me out. 17:04:48 <samccann> I hear ya gundalow 17:05:26 <abadger1999> samccann: is there a place docs people will meet and discuss this year? 17:05:44 <felixfontein> will this be text only, or text + voice (bluejeans)? 17:06:08 <samccann> abadger1999: acozine is there physically. I'll ask if she has any informal docs gathering planned 17:06:40 <samccann> Felixfontein - the bj links are in the etherpad pages. Which session are you looking for? 17:07:41 <felixfontein> samccann: I found the links, I'm just wondering whether it's needed - having audio input from two different meetings is hard to handle :) 17:08:20 <acozine> abadger1999: there is no official docs breakout today 17:08:25 <abadger1999> In previous years, most discussion was done via bluejeans with a little input via irc 17:08:42 <acozine> but if there's interest, I would be happy to gather a group 17:08:44 <abadger1999> acozine: Cool. If you have something feel free to let me know. 17:09:00 <rharolde> BlueJeans probably won't let you be in two meetings at once 17:09:20 <gregdek> Partner meeting is in #ansible-meeting-2 17:10:05 <felixfontein> rharolde: it does seem to work as a guest. though I don't have audio right now. 17:11:01 <gundalow> BlueJeans: https://bluejeans.com/3008457278/ 17:11:12 <samccann> I can attempt to keep up with the community breakout w/ notes here 17:11:23 <gundalow> samccann: Thank you 17:11:28 <samccann> So far: introductions around the room and what people hope to get out of this sesssion 17:14:49 <felixfontein> rharolde: it works, but effectively you cannot hear any of the two meetings... 17:16:04 <samccann> Discussing: what size should a collection be? 17:17:56 <samccann> many small collections could be annoying - lots of collections keywords/qualifying modules and tasks. 17:19:27 <samccann> #link https://docs.ansible.com/ansible/devel/user_guide/collections_using.html#using-collections-in-a-playbook 17:19:35 <samccann> using a collection in a playbook ^^ 17:19:39 <abadger1999> (nitzmahone) splits that account for distinct maintenance teams, release time lines, could be good 17:19:51 <gundalow> https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html 17:19:58 <gundalow> https://docs.ansible.com/ansible/devel/user_guide/collections_using.html 17:21:55 <abadger1999> Can we (virtual attendees) see what Option D is? 17:22:12 <samccann> a playbook or role could have 5-7 modules, each of which could be in a small collection (option D) 17:22:31 <samccann> as I'm hearing it, Option D is many small collections 17:22:42 <samccann> not sure what A-C is :-) 17:23:22 <felixfontein> (many small collections will make it harder to move stuff around. probably won't happen a lot, though :) ) 17:24:08 <gundalow> abadger1999: option D is collections at 2nd directory level of lib/ansible/modules/foo/HERE 17:24:09 <cyberpear> (how many raised hands?) 17:24:22 <felixfontein> what's A, B and C? 17:24:48 <samccann> one pro of small collections - might be easier to form a dedicated community/WG around that collection vs trying to support it as part of a larger collection 17:25:03 <bcoca> ^ also easier to do release cycles 17:25:12 <felixfontein> samccann, bcoca: +1 17:25:13 <bcoca> not have 'aci' modules depend on nxos ones ... 17:25:14 <samccann> similarly, might simplify the tests associated with that smaller collection 17:25:22 <bcoca> and requirements 17:25:49 <abadger1999> <nod> If there's separation of infrastructure for each colleciton (like different github repos) then a lot of other things become easy with somewhat smaller collectins too. 17:25:54 <bcoca> also consider that for installation, this is not a limitation as 'meta collections' do work 17:26:10 <samccann> also, smaller collection might help someone take over a community collection to make it certified for example. easier to migrate vs pull out from a larger collection 17:26:13 <abadger1999> But a balance is good.... teams, release cycles, etc. 17:26:37 <bcoca> all in one and one per plugin are extreemes, i think we can find happy mediums 17:27:13 <felixfontein> moving stuff (modules, plugins, ...) from one collection to another is probably hard (and requires duplicate code) 17:27:13 <FragmentedPacket> Are there defined requirements for the collections to be "certified"? 17:27:16 <gundalow> #info Need to prioritize user experience over developer experience 17:27:17 <samccann> bcoca: can you explain how the meta collection could simplify the earlier comments about having FQCN scattered throughout a playbook if the modules are all in different smaller collections? 17:27:56 <gundalow> FragmentedPacket: legal contracts + technical stuff 17:27:57 <bcoca> samccann: ansible.commuinity <= meta colleciton that has no content, just 'depedencies' that poign to 20-40 collections that are part of community and get installed when you 'install ansible.community' 17:28:11 <gundalow> so unlikely to get a Community certified collection 17:28:27 <bcoca> by def, community wont be certified 17:28:50 <geerlingguy> Yeah I would imagine most collections would have at least 5-10 'things' (between plugins/modules/roles) 17:29:18 <abadger1999> I don't think that will be sustainable for long. 17:29:33 <abadger1999> (the meta collection) 17:29:45 <bcoca> its just a list of deps 17:30:01 <bcoca> to 'emulate' the current community plugins, in the end i expect most people to do piecemeal 17:30:11 <bcoca> very few need azure + aws +nxos + vyos + .... 17:30:25 <bcoca> its a 'kitchen sync' .. which i think is not very useful to most users 17:30:32 <bcoca> but some will insist on it .. for now 17:30:33 <abadger1999> trying to externally keep deps working will be unmaintainable. 17:30:42 <abadger1999> Right now, those are all under our control. 17:30:53 <gundalow> #info Only Core Team from this room have played with Collections 17:30:55 <bcoca> ansible-community collection would aslo be under our control 17:31:05 <abadger1999> But once they're not under centralized control, keeping things working together gets much harder. 17:31:07 <geerlingguy> If it's purple output, it makes me nervous :D 17:31:09 <gundalow> #info there are 20 people in the room 17:31:21 <bcoca> abadger1999: true, but each collection should be mostly independant 17:31:23 <cyberpear> far cry from 130 earlier 17:31:25 <gundalow> #info core + ~5 people have looked at some of docs/webinar/blog 17:31:36 <abadger1999> bcoca: Oh, so we're going to continue to be the bottleneck of reviewing the changes to the content? 17:31:39 <bcoca> most of the ones i think we can include in 'community' 17:31:39 <gundalow> cyberpear: there are 3 breakouts happening now 17:31:41 <bcoca> abadger1999: no 17:31:44 <abadger1999> Exactly. 17:31:53 <cyberpear> each breakout have its own IRC or just main? 17:31:58 <abadger1999> and that's why it will become unmaintainable. 17:32:05 <bcoca> abadger1999: we are not the bottleneck now, community can mostly merge now w/o core involvment 17:32:09 <abadger1999> cyberpear: I believe they all have their own breakout. 17:32:11 <geerlingguy> abadger1999: earlier they mentioned giving more commit rights to working groups 17:32:12 <samccann> cyperpear: partner breakout is on #ansible-meeting-2 17:32:15 <abadger1999> *all have their own IRC 17:32:20 <bcoca> i would argue its as unmaintainable as current workflow 17:32:23 <geerlingguy> (which would be easier with a narrower breakdown) 17:32:25 <abadger1999> geerlingguy: exactly. 17:32:57 <bcoca> most of them already have 'commit' thouhg indirectly via shipit 17:33:25 <felixfontein> if no random thing blocks merging via shipit 17:33:45 <felixfontein> (like #commits != #authors if people use the github suggestion feature :) ) 17:33:52 <abadger1999> If we have a common meta collection like ansible.community, there needs to be a common decision making process/body/policy that can guide it to common places. If we don't have those things and no plan to do so, then a common meta collection is not going to work. 17:34:05 <samccann> 2.10 is the first release where maintainers have the option to move content out to collections 17:34:16 <bcoca> abadger1999: i would think the current 'sanity' tests would still apply to anything we ship 17:35:03 <geerlingguy> s/would/should (collections will need test structures set up once for each new repo—or if all in one, then in that repo) 17:35:04 <samccann> can envision active working groups deciding on their schedule for moving content. 17:35:25 <cyberpear> my opinion is that there should be a well-defined process for things included in the "batteries included" distribution, and should allow any modules that meet certain quality/guidelines/requirements, same as community modules today 17:35:47 <bcoca> ^ agreed 17:35:50 <abadger1999> But, for instance, (1) we aren't shipping it anymore... these ship on their own schedules in their own ways. (2) sanity tests can be ignored by a collection. A collection can choose which ones make sense and which ones don't. 17:36:10 <abadger1999> Without having common decision making, those things stop having meaning. 17:36:44 <abadger1999> (as someone said earlier, for instance, "which python versions does each collection support?") 17:36:44 <bcoca> a collection can ignore sanity tests, but if WE maintain a community one , we would not include versions that dont pass them in that meta 17:36:51 <abadger1999> bcoca: incorrect. 17:36:57 <abadger1999> We already do. 17:37:01 <gundalow> #info what's the smallest step that allows us to move in the right direction. IE can we just move some modules into a collection, the move others in later Ansible Release 17:37:05 <abadger1999> because they have good reasons to ignore them. 17:37:22 <geerlingguy> new collection name: "ansible.dumpster" 17:37:33 <abadger1999> And if we're not reviewing the changes, then we have to trust that collections are adding themselves to ignoring certain tests for good reasons as well. 17:37:43 <bcoca> geerlingguy: that is mostly what 'community' is right now 17:38:16 <ptoal> I think of community more as: "ansible.purgatory" 17:38:27 <gundalow> #info Some modules have "interesting" cross dependencies. IE VMware modules use module_utils/networking 17:38:36 <samccann> example of a challenge - vmware has its own module_utils, but also uses one in network. Dependencies become problematic if we move things out separately 17:39:30 <abadger1999> module_utils has technical solutions, though. 17:39:43 <abadger1999> We can do backwards compat for module_utils 17:39:57 <samccann> it's TBD how many of these unusual dependencies there are. 17:40:00 <abadger1999> (things which require fqn in a playbook is not as esay) 17:40:00 <felixfontein> I wonder how much will splitting into collections lead to code duplication 17:40:29 <bcoca> module utils is not only problem, plenty of people 'subclassing' modules 17:40:43 * geerlingguy just subclassed a module yesterday :O 17:41:04 <bcoca> modules really wont work, unless you force ALWAYS connection local 17:41:10 <abadger1999> subclassing modules doesn't work. 17:41:27 <geerlingguy> Tyler B predicts: Ansible 'next' will take as long as Python 3 to adopt (/s) 17:41:36 <abadger1999> But bcoca used quotes around subclassing so he might be doing something different ;-) 17:41:43 <geerlingguy> subclassing a class, not module 17:41:51 <abadger1999> geerlingguy: yep. that works. 17:42:06 <bcoca> abadger1999: people do really weird things 17:42:07 <abadger1999> Although I've grown to realize that is frequently a bad idea. 17:42:13 <abadger1999> bcoca: no... it's not possible. 17:42:17 <geerlingguy> but that class comes from a plugin that's part of core that's community so if it split out then my collection would need to change to point to that community collection... 17:42:17 <bcoca> even instanciating and monkey patching plugin 17:42:19 <geerlingguy> it gets complicated 17:42:26 <abadger1999> ansiballz doesn't allow it. 17:43:02 <abadger1999> <nod> With a plugin, you can do it. 17:43:19 <bcoca> abadger1999: did you add protection for that? cause i know people that were doing that and it 'worked' while conneciton was local 17:43:20 <abadger1999> but not modules. 17:43:31 <bcoca> same as using __init__.py in modules (we had a couple of cases that even made it into core) 17:43:44 <samccann> longterm it may be more desirable to use FQCN in playbooks instead of the collections keyword(s) 17:43:56 <abadger1999> Only working for connection local is not working to me. I think 2.9 will break it in some circumstances, too. 17:44:13 <felixfontein> it works with `connection: local` because it is using python to import the module directly, totally ignoring ansiballz. it won't work well with venvs though 17:44:16 <abadger1999> A side effect of relative imports working. 17:44:18 <bcoca> ok, 'workingish' on their test due to conneciton local 17:44:34 <samccann> (FQCN = fully qualified collection namespace) 17:44:36 <abadger1999> felixfontein: yep. 17:45:02 * geerlingguy still writes FQDN when I mean FQCN :P 17:45:03 <misc> I do not know who is speaking in crystal CD, but there is 2 people who were speaking at the same time 17:45:28 <samccann> me too geerlingguy! 17:45:39 <samccann> #topic - PR backlog 17:45:59 <rharolde> Can we have the existing name or location forever point to the new collection/name where a module or plugin has been moved? Whoever moves the module would need to update the pointer. 17:46:20 <fabianvf> abadger1999: when you say you can't subclass a module, are you talking about something other than this? https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/k8s/common.py#L264 https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/k8s/raw.py#L65 17:46:42 <rharolde> .. then nothing that depends on it would ever break. 17:47:42 <samccann> `needs_triage` - meeting 2x a week where core committers go in and review these, but not community issues 17:47:53 <gundalow> now talking: Sivel, who's describing how Core Team does triage of new issues & PRs for support:core that have arrived this week. Also once a week they look at oldest 17:48:14 <abadger1999> fabianvf: yes, something different. Like, You can't subclass KubeVirtPVC from here: https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/kubevirt/kubevirt_pvc.py#L311 17:48:26 <gundalow> #info Core Team can "only" get through 10 old issues/PRs 17:48:36 <abadger1999> fabianvf: It's inside of an ansible module (lives in lib/ansible/modules) rather than inside of a module_utils. 17:49:11 <fabianvf> abadger1999: ah ok, so you can subclass an `AnsibleModule`, but you can't subclass anything from the `modules/` directory 17:49:21 <samccann> #info PR review days in IRC - can get through around 50 in a long day. 17:49:32 <abadger1999> fabianvf: although, as I also hinted, subclassing a class inside of a module_utils has to be done carefully... it's relatively easy for a base class to break a subclass. 17:49:37 <abadger1999> fabianvf: yep. Correct. 17:49:38 <felixfontein> fabianvf: at least not without dirty tricks (like connection:local or having ansible installed on the remote host as well) 17:49:52 <geerlingguy> (unless you control both the base class and subclass) 17:50:14 <abadger1999> felixfontein: Yep. Although the 2.9 relative import feature will break those tricks in certain circumstances. 17:50:46 <abadger1999> geerlingguy: yep. But, for instance, everyone subclassing AnsibleModule is probably doing it wrong ;-) 17:50:53 <fabianvf> abadger1999: yeah I'm definitely familiar with the breakages, but there's enough shared logic that inheriting the fixes has been worth it thus far 17:51:42 <felixfontein> did that 17:51:47 <bcoca> i've done it a couple of times 17:51:53 <gundalow> #action gundalow Speak to GitHub to see if we can get view count for Issues/PRs 17:52:00 <gundalow> felixfontein: was that Docker? 17:52:00 <bcoca> mostly cause i makred them during triage and figured it out later 17:52:01 <felixfontein> (when I thought the feature makes sense, and was interested in the feature and/or module) 17:52:06 <felixfontein> gundalow: docker and/or crypto 17:52:09 <abadger1999> geerlingguy: also, an issue that I saw today was someone subclassing a module class. But then not using the base class's argspec as the base of their module's argument spec... that is equally fragile. 17:52:29 <gundalow> felixfontein: ack, thanks 17:52:56 <felixfontein> I also sometimes create feature requests as a reminder of stuff that could/should be implemented, but I don't want / can implement now (because of lack of time, ...) 17:54:21 <geerlingguy> "drive by contributions" (as mentioned earlier) 17:54:31 <abadger1999> fabianvf: https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/aws/core.py#L121 <=== that's what we did for the AnsibleAWSModule base class instead of subclassing. It's a bit more robust. 17:54:40 <felixfontein> like people searching for the feature, finding the request, and implementing it :) 17:55:40 <abadger1999> fabianvf: people don't like it because it requires that you have to write more boilerplate. But it's better because AnsibleModule won't do something like add a new attribute that then is shadowed by something in your subclass. 17:56:02 <gundalow> #info Do we need to get better at saying "no" to incoming feature requests 17:56:44 <felixfontein> which projects are this? 17:56:46 <fabianvf> abadger1999: yeah I'll have to unpack what that's doing later 17:57:06 <geerlingguy> yes to 'Do we need to get better at saying "no" to incoming feature requests' 17:57:14 <gundalow> #info Closing is about expectation management 17:57:20 <abadger1999> fabianvf: it's basically composition instead of inheritance. 17:57:40 <geerlingguy> Best happy medium IMO is what K8s community bot does, with the 90-day-stale thing 17:57:47 <bcoca> zombie land 17:57:48 <gundalow> #info a closed issues is just as easy to find as an open issue. AND makes the open issues easier to find 17:57:48 <felixfontein> tagging is good, so you can distinguish between implemented feature requests and not implemented feature requests (both are closed) 17:57:56 <geerlingguy> easy enough to mark as 'not stale' or as 'never stale' (anyone can do it via comment) 17:58:05 <fabianvf> +1 to stale bot, if the issue still has interest it's easy to bump it 17:58:37 * geerlingguy just wants ansibot to have like 10,000 more loc 18:00:14 <bcoca> my list is aprox 300 ... still tiny, probably overlaps with his a lot 18:00:57 <fabianvf> as a module maintainer my list is generally ~50 18:01:00 <samccann> discussion: how many of the current issues backlog are possible targets for some developers here. 18:01:00 <geerlingguy> We could close 627 community feature requests within 90 days :) 18:01:04 <felixfontein> except if the closed one is locked 18:01:34 <gundalow> geerlingguy: as in just adds `needs_info` to the 627 label/support:community label/feature 18:01:36 <geerlingguy> felixfontein: then just open a new dupe feature (if necessary) 18:01:46 <abadger1999> felixfontein: Yes... that should be mentioned 18:01:46 <sivel> samccann: if you are looking for good intro issues the easyfix label might help 18:01:53 <felixfontein> geerlingguy: then it's harder to keep track of how many people are interested 18:02:05 <abadger1999> @gundalow ^ Mention that closed issues and PRs get locked 18:02:08 <felixfontein> (and more stuff to actively close) 18:02:29 <geerlingguy> true, but if someone closes an issue, it pops up again, then opened again, etc... either there's a troll, or it's something that should be dealt with 18:02:36 <samccann> sivel: agree - the `easyfix` label has helped us get community folks to take on some docs issues 18:02:51 <bcoca> bot 18:02:54 <bcoca> named sivel 18:02:59 <felixfontein> hehe 18:03:11 <felixfontein> the first two times I've seen it, I was wondering whether sivel does it manually :) 18:03:47 <felixfontein> maybe closed feature requests (which aren't implemented) shouldn't be locked? 18:03:56 <geerlingguy> felixfontein++ ^^ 18:04:18 <geerlingguy> I don't like locking issues as a general rule... 18:04:36 <geerlingguy> a lot of times someone comes into a really old issue and adds some really good info (for future people who run into it again) 18:04:48 <bcoca> many times unrelated to ticket discussion 18:05:25 <felixfontein> for bugfixes and merged PRs and implemented features, I think locking is a good idea in general (if you have a problem with it, open a new issue). though there are exceptions @geerlingguy 18:05:29 <geerlingguy> but to the point above ( felixfontein's ) — just don't lock closed feature requests 18:05:45 <felixfontein> geerlingguy: I'd still lock them if they have been implemented :) 18:05:54 <mnaser> for those who want to hack on openstack module PRs: https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Aopenstack+label%3Aneeds_triage 18:06:09 <bcoca> rewrite ansible in ruby STAYS LOCKED 18:06:22 <felixfontein> does that one actually exist? 18:06:23 <geerlingguy> shipit 18:06:26 <cyberpear> I hate locked items 18:06:38 <geerlingguy> close it, don't lock it 18:06:57 <bcoca> its mostly to remove illusion from users that they actually let us know anything 18:07:44 <geerlingguy> it would be cool if github issue queues themselves had a 'stale issue' functionality 18:08:11 <bcoca> 3,6,9 months all work for me 18:08:24 <bcoca> my filter is any issue closed >15 days gets ignored 18:08:31 <cyberpear> I can't comment on my own PR if it's locked 18:08:37 <abadger1999> locking seems reasonable to tie to "Will anyone see new comments here"? 18:08:42 <bcoca> you can prod us to unlock 18:09:13 <felixfontein> bcoca: that only works well if you know how to contact "us" easily, like on IRC :) 18:09:23 <abadger1999> So it seems more like "what length will bcoca change his filter to match what the bot does?" ;-) 18:09:28 <bcoca> or ML 18:09:35 <abadger1999> Or in a new issue. 18:09:43 <fabianvf> I also find locking pretty frustrating, unless the last comment is the de-facto solution and the whole discussion has clearly played out. Generally erring towards locking ends up feeling very anti-user, at least to me 18:09:46 <geerlingguy> Sounds like Ansibot needs more Watson integration ;) 18:10:08 <bcoca> fabianvf: normally 'def facto solution' is 7 posts up and we close cause people keep appending misinformation 18:10:15 <geerlingguy> fabianvf++ same here, I generally see locking as "this discussion was off the rails, so it was locked" 18:10:24 <bcoca> or asking same question, w/o reading answers 18:10:37 <geerlingguy> not "it's old so it's locked" (unless there's a spam problem, which thankfully GitHub seems to not have) 18:10:43 <fabianvf> bcoca: even then if you're going to lock it the best solution should be the last comment IMO 18:10:51 <cyberpear> fabianvf: 18:10:55 <cyberpear> ++ 18:11:00 * geerlingguy in general, outside ansible/ansible when I see locked I feel offended :P 18:11:14 <braindeaddev> lol 18:11:16 <bcoca> fabianvf: easy to do with manual locking, not easy with 'time/automated one' 18:11:18 <cyberpear> geerlingguy++ 18:11:29 <bcoca> if i lock due to 'off rails' my comment normally links 'solution above' 18:11:31 <fabianvf> bcoca: well I'm arguing against time/automated locking :P 18:11:45 <bcoca> fabianvf: manually locking thousands of issues is not scalable 18:11:58 <cyberpear> doesn't affect those on the repo, but that's not most folks 18:12:04 <fabianvf> bcoca: do thousands of issues need to be locked though, or just closed? 18:12:04 <geerlingguy> unsubscribe is a thing though 18:12:12 <cyberpear> why lock at all? 18:12:17 <bcoca> locked, tons of people still comment on closed issues 18:12:20 <geerlingguy> ^ if the problem is notifications, unsubscribe from the issue 18:12:24 <bcoca> cyberpear: cause WE DO NOT SEE THOSE 18:12:30 <cyberpear> geerlingguy++ 18:12:42 <bcoca> people get frustrated as they expect maintainers to respond 18:12:52 <geerlingguy> people are dumb, just ignore them :) 18:12:55 <cyberpear> users can still help each other 18:12:55 <bcoca> this is not for us ... we dont see it already ... its for users posting into ether 18:13:16 <bcoca> yet they rarely do in closed issues, its mostly list of 'is anyone going to respond, this is still and issue!!!' 18:13:19 <geerlingguy> but they should get used to it 18:13:29 <rharolde> Can you show use A,B,C,D ? 18:13:32 <geerlingguy> I see tons of "I'm having this problem" comments when I'm browsing project issues on GitHub 18:13:53 <cyberpear> ansibot could learn to respond on old issues 18:14:04 <bcoca> geerlingguy: i think that is poor user experience 18:14:12 <geerlingguy> meh 18:14:19 <geerlingguy> it's the standard everywhere on GitHub 18:14:20 <bcoca> cyberpear: at one point i fear asnibot will take over roombas and end humanity 18:14:21 <cyberpear> bbn it 18:14:26 <fabianvf> from a user perspective, locking issues feels actively hostile and turns me off a project 18:14:29 <bcoca> geerlingguy: standard != good 18:14:35 <geerlingguy> no but it's expected 18:14:35 <cyberpear> fabianvf: 18:14:44 <geerlingguy> and I don't believe locking issues == good 18:14:47 <cyberpear> agreed 18:14:50 <fabianvf> agreed 18:14:53 <bcoca> fabianvf: depends on how you lock, we have message explaining 'we dont see old issues, please open new one' 18:15:02 <geerlingguy> like I said, outside of ansible/ansible, locked is kind of an offensive thing unless you were being a troll 18:15:04 <bcoca> locking and not saying anything ... 18:15:14 <cyberpear> it's hard to find the new issue 18:15:24 <bcoca> not find, open 18:15:30 <bcoca> most times, there is NO new issue 18:15:33 <cyberpear> yes drive 18:15:35 <cyberpear> find 18:15:38 <bcoca> if anyone creates one, we do instruct 'link old issue' 18:16:03 <rharolde> I hear talk about options A/B/C/D, but no explanation of what those are. 18:16:05 <geerlingguy> but you can't link old to new (and old is the one you get from Google) 18:16:09 <bcoca> so those going to old issue, should see link to new 18:16:15 <cyberpear> will old issue show link to new one? 18:16:21 <bcoca> geerlingguy: github shows linked issues by default 18:16:33 <bcoca> no, new -> ref #old, then in old history you see 'new' 18:16:34 <cyberpear> even utf created by external user? 18:16:38 <geerlingguy> rharolde: A/B/C/D is spectrum of A being "one giant collection with everything" vs D being "one collection for every folder in ansible/ansible modules" 18:16:47 <bcoca> cyberpear: even if you reference in diff project 18:16:48 <rharolde> thanks 18:16:53 <geerlingguy> bcoca: true 18:17:02 <cyberpear> even for locked? 18:17:06 <bcoca> yes 18:17:09 <geerlingguy> but I ignore those things because everyone is always linking to popular issues 18:17:19 * cyberpear tries 18:17:23 <geerlingguy> Anyways, I'm still on team don't-lock 18:17:24 <bcoca> so basically we cannot win with you? 18:17:48 <cyberpear> also "don't lock" vote from me 18:18:03 <bcoca> we should schedule for irc meeting 18:18:05 <geerlingguy> You can, if autolock is disabled. Manually lock if the need arises, this is how every other community I'm in on GitHub works 18:18:10 <geerlingguy> closing can be automated 18:18:10 <cyberpear> who without commit eus 18:18:16 <fabianvf> yeah locking is best reserved for trolls IMO 18:18:25 <sivel> I don't think that's going to happen. To be frank we'll always lock issues to help us maintain sanity 18:18:26 <cyberpear> rights wants to lock? 18:18:28 <bcoca> we lock issues, not people out 18:18:38 <bcoca> we dont lock an issue due to troll, we ban troll 18:19:00 <misc> ùhh, I can't hear what is said in community room 18:19:27 <ptoal> misc: Some folks are forgetting to speak in to the microphone. :) 18:20:09 <geerlingguy> sorry :( 18:20:14 <bcoca> change will get noise, either way, the question is if that noise is due to sake of change or cause change is actually bad 18:21:12 <felixfontein> which dots? 18:21:18 <felixfontein> there's no screen sharing active 18:21:19 <clarkb> mnaser: see os_stack.py and grep for min_version 18:21:23 <clarkb> mnaser: that is one place where this is checked 18:21:29 <abadger1999> @gundalow are you able to share screen? 18:21:33 <bcoca> dots are imaginary! 18:21:45 <felixfontein> it's all so complex! 18:21:55 <bcoca> we 'collect' everything 18:22:32 <clarkb> mnaser: note my checkout might be old 18:22:37 <abadger1999> (sivel) We'll likely be shipping the modules in core frozen in time for a period of time even after they're moved to collections 18:22:41 <bcoca> `migrated_to` 18:22:55 <ptoal> http://dash.tannerjc.net/graph Query: repo ansible/ansible Tick backlog 18:23:19 <felixfontein> yay, there's something to see! 18:23:26 <geerlingguy> we are now DDoSing jtanner's server :P 18:24:28 <ptoal> What, it doesn't auto-scale with an ansible operator? ;) 18:25:07 <bcoca> cc limit 18:25:20 <geerlingguy> ha, I don't think jtanner's had time to split that thing into microservices and ship it on serverless yet 18:25:30 <bcoca> its also on his 'personal' cloud 18:26:05 <sivel> I also mentioned our kibana instance, which is at https://kibana.eng.ansible.com/ 18:26:19 <sivel> You have to write your own queries, nothing really pre-built 18:26:20 <misc> if we make the server crash, it goes serverless by definition 18:26:56 <bcoca> therapy 18:27:04 <samccann> heh 18:28:13 <gundalow> Working Groups: https://github.com/ansible/community/wiki 18:28:57 <gundalow> DING DING Change over in 15 minutes 18:32:11 <jtanner> https://tannerjc.net/wiki/index.php?title=Ansible_Developer_Filament 18:33:38 <gundalow> Thanks, everybody 18:33:41 <gundalow> #endmeeting