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