18:00:17 <felixfontein> #startmeeting Ansible Community Meeting
18:00:17 <zodbot> Meeting started Wed Mar 31 18:00:17 2021 UTC.
18:00:17 <zodbot> This meeting is logged and archived in a public location.
18:00:17 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:17 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:17 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:20 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping!
18:00:25 * dericcrago waves
18:00:27 <cybette> o/
18:00:28 <abadger1999> Good evening
18:00:29 <tadeboro> o/
18:00:36 <andersson007_> o/
18:00:41 <felixfontein> #chair dericcrago cybette abadger1999 tadeboro andersson007_
18:00:41 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago felixfontein tadeboro
18:01:02 <felixfontein> hi everyone :)
18:01:09 <felixfontein> #topic Updates
18:01:09 <felixfontein> #info Topics for today's meeting: https://github.com/ansible/community/issues/539#issuecomment-811147666
18:01:15 <felixfontein> #info Ansible 3.2.0 has been released
18:01:15 <felixfontein> #info Ansible 4.0.0 alpha 3 has been released
18:01:22 <dmsimard> o/
18:01:28 <felixfontein> #chair dmsimard
18:01:28 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein tadeboro
18:01:54 <felixfontein> #info ansible-core 2.11.0 beta 4 released, RC expected next week
18:01:54 <lmodemal> Hello \o/ I am lurking today. Nanny called out so I am on kids duty.
18:02:01 <felixfontein> #chair lmodemal
18:02:01 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein lmodemal tadeboro
18:02:06 <acozine> o/
18:02:11 <felixfontein> #chair acozine
18:02:11 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette dericcrago dmsimard felixfontein lmodemal tadeboro
18:02:24 <felixfontein> lmodemal: we'll try not to ping you too much ;)
18:02:39 * gundalow waves
18:02:43 <tadeboro> lmodemal: Give them a keyboard and let the fun begin ;)
18:02:50 <felixfontein> #chair gundalow
18:02:50 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette dericcrago dmsimard felixfontein gundalow lmodemal tadeboro
18:03:07 * gundalow sits
18:03:18 <felixfontein> considering the potential topics for today: https://github.com/ansible/community/issues/539#issuecomment-811147666 is there anything else you want to discuss, adjust the order, ...?
18:04:24 <lmodemal> felixfontein: lol that's asking for trouble
18:05:13 <felixfontein> does anyone else have updates?
18:05:24 <abadger1999> not I
18:05:45 <dmsimard> Maybe a reminder that there is a poll for next contributor summit date
18:05:47 * dmsimard finds link
18:05:50 <dericcrago> there are some "testing" PPAs for ansible, more info can be found at https://github.com/ansible-community/ppa/issues/1
18:05:51 * samccann waves
18:06:10 <cybette> #info Please help determine the date of next Ansible Contributor Summit by voting here https://www.surveymonkey.co.uk/r/RBMJFXS
18:06:13 <felixfontein> #chair samccann
18:06:13 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette dericcrago dmsimard felixfontein gundalow lmodemal samccann tadeboro
18:06:18 <felixfontein> thanks cybette!
18:06:30 <cybette> thanks for the reminder dmsimard  :)
18:06:31 <dmsimard> cybette: ah, there it is, thanks :)
18:06:41 <dericcrago> the testing PPAs have Ansible 2.10.7 & 3.1.0 (soon to be 3.2.0) for Ubuntu (18.04, 20.04, 20.10)
18:07:46 <dmsimard> dericcrago: do you want to #info that
18:07:47 <felixfontein> #info the testing PPAs have Ansible 2.10.7 & 3.1.0 (soon to be 3.2.0) for Ubuntu (18.04, 20.04, 20.10)
18:07:57 <dmsimard> ah, felix beat us to it :p
18:08:05 <felixfontein> :)
18:08:18 <tadeboro> Are the resilts for that survey available anywhere? I cannot remember if I voted already or not.
18:08:29 <felixfontein> anything else? if not, let's start with the LTS question
18:08:50 <felixfontein> tadeboro: I wondered that too (whether I voted). but I think all dates are fine for me (with the current state of my agenda), so it doesn't really matter
18:09:08 <felixfontein> #topic What are the implications of maintaining and supporting past major releases of the ansible package
18:09:11 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/1
18:09:14 <felixfontein> #info writeup: https://hackmd.io/plQlGzcFRFGLnPXIeg3cwQ
18:09:18 <felixfontein> dmsimard: do you want to 'present' this?
18:09:23 <dmsimard> sure
18:09:45 <dmsimard> In a nutshell, Ansible has historically supported versions N, N-1 and N-2
18:10:37 <dmsimard> With our adoption of semantic versioning and the split to ansible-base^Wansible-core, we need to review our expectations in terms of support
18:10:55 <cybette> tadeboro: if you have responded, you'll see "You have already taken this survey". or if you cleared the cookie, then just respond again, no worries :)
18:11:38 <dmsimard> At a high level, ansible (the community package) provides ansible-core and then a curated list of collections with the maintenance provided by each upstream (collection) or ansible-core itself
18:11:38 <felixfontein> I like the idea of supporting both N and N-1
18:11:57 <acozine> can we talk about "maintenance" instead of "support"?
18:12:07 <tadeboro> cybette: I always fill surveys in private windows, so no electronic biscuites for me ;)
18:12:17 <felixfontein> acozine: you mean to distinguish it from Support with captial S?
18:12:21 <acozine> yeah
18:12:38 <cybette> tadeboro: lol, that's great :)
18:12:40 <acozine> we're not going to give folks a support line they can call, we're just thinking about backporting bugfixes
18:12:42 <abadger1999> maintenance and updates are unambiguous whereas support overlaps with contracts and payment and those expectations
18:12:56 <dmsimard> sure, FWIW I think we're on the same wavelength here -- apologies for the vocabulary :)
18:13:14 <acozine> dmsimard: yeah, I knew what you meant
18:13:46 <acozine> just before anyone #info's this and someone starts with "but in these meeting minutes it says . . . "
18:13:53 <dmsimard> aye :)
18:14:19 <dmsimard> so, with 2.10.x already behind us, the question could be simply put as: should we continue releasing minor updates to 3.x once 4.x is out and if so, how and is the devil hidden in the details
18:14:30 <felixfontein> I think most collections fall in one of the two categories: small(er) collections which very seldomly release major versions; these will always have newer minor/patch releases (except in few rare cases); and larger collections like c.g / c.n with regular major releases, but these usually backport bugfixes
18:15:01 <felixfontein> so if we are talking about more minor Ansible releases (as opposed to bugfix-only releases), we don't have to worry about collections no longer having new versions
18:15:34 <cybette> cyb-clock chimes: it's 15 min past the hour
18:15:37 <dmsimard> felixfontein: this could mean shipping outdated collections or unfixed security issues if the upstream no longer ships/backports fixes
18:15:38 <acozine> so most of the work is straightforward release management?
18:16:09 <felixfontein> dmsimard: true, but I wanted to say with that that this isn't an issue for most collections, since most won't have had a major release
18:16:26 <felixfontein> where 'most' of course is a relative concept :)
18:16:51 <andersson007_> c.g. contains more stuff then all the other together:)
18:17:07 <felixfontein> some smaller collections will probably also create stable branches for older versions once they do a first new major release (c.docker and c.crypto will for example)
18:17:30 <samccann> The 'what if' that comes to mind for me - what if a collection has a CVE but doesn't fix it in the minor version in Ansible 3.x  yet we ship Ansible 3.x with the CVE fix for other collections/core.  It's still a security problem, but how to explain that to users?
18:17:35 <tadeboro> I think the real question is: do we backport bugfixes from collections that do not have "LTS" versions?
18:17:54 <felixfontein> and I guess the Supported collections will also fix older versions if serious bugfixes or security fixes appear
18:18:02 <dmsimard> samccann: yes, that's one of the "devil is in the details" point
18:18:31 <tadeboro> Because LTS that only has part of content supported is probably worse than no LTS at all.
18:18:41 <tadeboro> s/supported/maintained
18:18:47 <felixfontein> :)
18:18:56 <dmsimard> tadeboro: we do not necessarily have maintainer rights on all collections and so we might not even be in a position to merge fixes
18:19:12 <samccann> so the 'pros' is someone who wants to stay on say core-2.11 can continue to get updates and get collection minor updates for those who have them.  The 'cons' is there isn't an easy/clear way to say 'user beware.. some collections may not maintain security fixes, consider upgrading to Ansible 4'
18:19:13 <dmsimard> patching collections at build time is not a territory I think we want to get into
18:19:28 <felixfontein> what dmsimard said
18:19:38 <samccann> yeah I'm leaning toward what tadeboro said
18:20:08 <dmsimard> a potential alternative for users looking to "stay" on 3.x would be to install ansible-core and then cherry-pick the collections they want
18:20:26 <felixfontein> if we know about unfixed CVEs, we could add a known issues entry in the Ansible changelog for that
18:20:31 <acozine> I think that is the safer approach
18:20:53 <acozine> (let users cherry-pick collections on top of older package versions)
18:21:05 <dmsimard> felixfontein: I think it would not reflect well to knowingly ship something that has a CVE against it
18:21:36 <felixfontein> dmsimard: true. but not shipping new versions just because we know some collection has a CVE and doesn't want to fix it isn't much better either IMO
18:22:06 <dmsimard> but the fix might be in 4.x or out-of-band through galaxy though
18:22:21 <felixfontein> what do we do if we are aware of a CVE in the latest version of a collection, but the collection ignores it? will we stop doing any Ansible release from that point on?
18:23:13 <dmsimard> felixfontein: I would consider that a serious issue and potentially a blocker until remediated or worked around, yes
18:23:25 <felixfontein> for example Ansible 3.2.0 did ship some collections which have unfixed security issues (because the collection(s) in question did not do a release after they were fixed yet)
18:23:38 <tadeboro> I have a hard time imagining how LTS would work since we do not have control over the content we ship in ansible package.
18:24:02 <dmsimard> tadeboro: there are LTS versions of linux distributions and they do not control upstreams :)
18:24:12 <abadger1999> tadeboro: Yeah, that's the heart of the matter.
18:24:32 <tadeboro> dmsimard: SO they at least partially patch those packages themselves.
18:24:36 <gundalow> felixfontein: you said `some smaller collections will probably also create stable branches for older versions once they do a first new major release (c.docker and c.crypto will for example)`. Do you think others would do that?
18:24:45 <abadger1999> dmsimard: I think tadeboro is making the point that distributions can patch the source in their downstream but we currently cannot/do not.
18:24:59 <dmsimard> ^ yes, understood
18:25:09 <felixfontein> gundalow: I hope so :) though I guess it depends on the collection maintainers. I think andersson007_ might do that for c.mysql and c.postgresql, but I'm not sure about others
18:25:20 <samccann> ah so a distribution that can patch does not knowingly ship a version w/ a CVE then?
18:25:24 <dmsimard> legal and bandwidth issues aside, I don't see us doing that
18:25:27 <gundalow> I guess if a CVE is reported and a collection has bumped major release we can always retrospectively create a `stable-` branch based on the tag
18:25:38 <tadeboro> Some maintainers are having troubles following the semver. And I cannot imagine how well the "please backport security fixes to some branch" would go over.
18:26:10 <andersson007_> we'll release a major version of c.mysql soon
18:26:18 <felixfontein> for example for debian's oldstable, it sometimes takes weeks for CVE fixes to be backported (probably because it's really hard work, since the oldstable codebase is several years old...)
18:26:22 <gundalow> tadeboro: that's a better phrased version of what I was asking. Thanks
18:26:34 <dmsimard> felixfontein: let me get back to that 3.2.0 CVE thing later so we don't sidetrack, I'd like to know more
18:27:09 <felixfontein> dmsimard: sure, I can also /msg you details
18:28:21 <abadger1999> felixfontein: About shipping collections with known CVEs, I think you are correct that currently we're defaulting to continuing to ship if there are known CVEs in a contained collection.  We might want to have some policy in place about that (maybe hinging on how critical the security issue is) Also, so far we haven't had to deal with CVEs that are only in a new collection release.
18:28:44 <abadger1999> I think we would definitely want to pin to an old version if that case comes up.
18:29:31 <dmsimard> I want to leave time in the meeting for other topics but the discussion was already productive -- unless there are any strong arguments in favor of LTS (considering alternatives) I would tend to lean on not doing it and can write a proposal in that direction we could vote on next meeting
18:29:34 <felixfontein> the old version will also have that CVE though
18:30:21 <felixfontein> can we have a quick poll (+1 = LTS, -1 = no LTS, or something inbetween)?
18:30:31 <felixfontein> just to have some numbers
18:30:39 <cybette> cyb-clock chimes: 30 min past the hour! and 21 min on topic "implications of maintaining past major releases"
18:30:41 <felixfontein> #chair
18:30:41 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette dericcrago dmsimard felixfontein gundalow lmodemal samccann tadeboro
18:30:44 <abadger1999> <nod> I'm thinking of two different scenarios... if the CVE is present in old versions, we might as well update as it isn't a regression.  If the CVE is only in the newer update, pin to the old version until the cve is fixed.
18:30:48 <samccann> LTS is desirable, but I'm not seeing a viable solution to security problem
18:31:01 <felixfontein> POLL (non-binding): +1 = LTS, -1 = no LTS, or something inbetween
18:31:15 <felixfontein> +0.9
18:31:18 <felixfontein> :)
18:31:27 <mariolenz> community.vmware doesn't really has a "stable" release. at the moment, we're on (collection) version 1.8. but it's the main branch. maybe this collection should have a 1.x branch so features / bugfixes can be backported to this in case ansible 3 includes community.vmware 1.something and ansible 4 includes community.vmware 2.something breaking downwards compatibility. similar to how ansible itself worked, having a devel bra
18:31:29 <mariolenz> nch and branches for 2.7, 2.8, 2.9... other collections might have the same problem.
18:31:35 <misc> what about requesting that LTS backport fix when possible ?
18:31:36 <abadger1999> +0... LTS is desirable but someone would have to write a proposal that addresses these issues (even if the proposal is "We will document the shortcomings prominently for users to know")
18:31:37 <samccann> -1 if we can't find an understandable way to update in the presence of an unfixed CVE
18:32:03 <tadeboro> -1 (because we do not package things ourselves)
18:32:16 <andersson007_> -1
18:32:47 <felixfontein> mariolenz: c.crypto and c.docker will start a stable-1 branch once 2.0.0 is released, so we can backport bugfixes (or even features if someone wants to invest the work). but until 2.0.0 is up, there's no need for a stable branch. and the main releases (for the current major version) will always happen from main
18:32:59 <dmsimard> heh, -0.5 ? as in, I would like us to do it but it doesn't feel realistic due to the burden/hoops involved and there are good alternatives available (ex: ansible-core with cherry-picked collections)
18:33:19 <samccann> the alternative - we update UNTIL there is an unfixed CVE, and then abandon that version in favor of something that does have a clean security fix.
18:33:33 <abadger1999> misc: Yeah, we could request that the upstream collections backport fixes for a period of time.  However, currently , most upstream collections don't even have stable branches to backport to.
18:33:40 <felixfontein> samccann: that quickly gets very, very messy :)
18:33:49 <acozine> 0 it's an appealing idea but takes a lot of work and tracking, and is hard to communicate
18:33:49 <samccann> heh yep it does!
18:33:58 <misc> I also wonder if we need different answers for different types of CVE
18:33:59 <cybette> -0.5 what dmsimard said
18:34:08 <felixfontein> abadger1999: on the other hand, most upstream collections do not need a stable branch because there's no older major version (if you ignore 0.x.y)
18:34:18 <felixfontein> +yet
18:34:33 <misc> (cause, "we forgot to add no log on a parmater" do not seems like lot of effort to backports, for example)
18:34:38 <abadger1999> felixfontein: true.  So it may be too early to take that raw statistic as giving much information
18:35:21 <gundalow> 0.5 I'm not seeing the real benefits for the current setup. If more collections had `stable` branches I might change my mind
18:36:07 <abadger1999> misc: Yep.  But backporting the code is only one piece.  It also means the upstream will need to maintain a branch for fixes to an older version and make releases from it.
18:36:47 <abadger1999> Could we poll collection owners to see if they're interested in doing this extra work?
18:36:55 <felixfontein> ok thanks everyone! I think it's time to continue with the next topic
18:37:06 <felixfontein> #topic Licenses for new collections: Apache 2.0
18:37:06 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/2
18:37:09 <felixfontein> #info hpe.nimble (https://github.com/ansible-collections/ansible-inclusion/discussions/13) is Apache 2.0 licensed (https://github.com/hpe-storage/nimble-ansible-modules/tree/master/ansible_collection/hpe/nimble#license)
18:37:42 <felixfontein> right now we explicitly say that only GLPv3+ and BSD (for module utils) is allowed in collections to be included in Ansible
18:38:41 <dmsimard> I thought modules needed to be GLPv3 because they imported from Ansible ?
18:39:03 <tadeboro> No, modules are the only code that can be non-GPLv3
18:39:06 <abadger1999> <nod>  I would like to relax that but some people wanted red hat legal to okay relaxing.
18:39:34 <mariolenz> felixfontein: thanks for the information :-)
18:39:58 <felixfontein> if we don't relax the rule, we won't be able to accept hpe.nimble because of that (assuming they don't want to change the license)
18:39:59 <abadger1999> dmsimard: plugins must be gplv3 (there's some hairsplitting that I could go into but it's an ok simplification)  but modules are separated by a process boundary so they can be non-GPLv3
18:40:15 <dmsimard> abadger1999: ah, distinction between plugins and modules. Got it.
18:40:28 <abadger1999> FYI: red hat legal has not replied to my ticket yet.
18:40:33 <felixfontein> btw, out of curiosity, what about data files that are used by plugins/modules?
18:41:19 <abadger1999> I need to ask that as a separate question.  I'm not familiar enough with that area to know what the answer would be.
18:41:20 <felixfontein> for example https://publicsuffix.org/list/public_suffix_list.dat is licensed under the Mozilla Public License. if a collection would like to include that file (and read it from plugins), can we accept them?
18:41:53 <Tas-sos> Hello o/
18:41:53 <Tas-sos> I wanted to attend today's meeting, but now I am back..
18:42:08 <abadger1999> felixfontein: I probably should have a specific example to explain to legal about it, if you can point me to a collection that is using data under another license.
18:42:12 <abadger1999> #chair Tas-sos
18:42:12 <zodbot> Current chairs: Tas-sos abadger1999 acozine andersson007_ cybette dericcrago dmsimard felixfontein gundalow lmodemal samccann tadeboro
18:42:53 <abadger1999> (If you can send me one, I'll write up a question around it.)
18:43:17 <cybette> have they responded that they are not willing to change the license?
18:44:16 <felixfontein> cybette: not that I know of. but then, I didn't ask explicitly
18:44:39 <felixfontein> (https://github.com/ansible-collections/ansible-inclusion/discussions/13#discussioncomment-524681, search for 'licens')
18:45:42 <cybette> yeah I didn't see any direct response specific to the license
18:46:51 <cybette> cyb-clock chimes: 45 min past the hour! and 8 min on topic "Licenses for new collections: Apache 2.0"
18:47:03 <felixfontein> I think allowing Apache 2.0 is better long-term anyway, since that seems to be pretty common
18:47:11 <felixfontein> ok, I guess there's not much we can discuss for this topic
18:47:32 <abadger1999> I would like to relax the license requirement for modules.
18:48:04 <abadger1999> I'm pretty sure legal would okay it on multiple grounds (the ansible package is a mere aggregation.  Apachev2 license is compatible with the GPLv3+)
18:48:35 <abadger1999> But if other steering committee members want to wait for red hat legal's explicit okay, then we can continue to wait.
18:49:25 <felixfontein> is there a rough idea on how long it can take for them to answer?
18:49:40 <felixfontein> i.e. how probable is it that they answer before the inclusion deadline is reached?
18:50:05 <abadger1999> Fontana did answer a different legal question for us recently.  Sot hat's hopeful.  But that question was asked over six months ago.  So that's the opposite of hopeful.
18:50:30 <felixfontein> hmm. maybe they forgot about it? :)
18:50:32 <abadger1999> I'd say before the inclusion deadline for 4.0 is in the not likely range.
18:50:37 <felixfontein> (no idea how the system works)
18:51:53 <felixfontein> I'm a bit tending in the direction of waiting, but I don't like the idea of having to wait 'forever'
18:51:58 <abadger1999> Yeah
18:52:28 <abadger1999> Should I make a proposal for next meeting (relax the rules to allow moduleslicensed with GPLv3+ compatible license) and we can vote on that then?
18:52:38 <felixfontein> sgtm
18:52:41 <felixfontein> any other opinions? :)
18:52:43 <abadger1999> Cool.
18:53:11 <felixfontein> #topic Meta: how to add things to the agenda
18:53:11 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/3
18:53:14 <felixfontein> #info New repository for tracking topics and discussions for the meetings: https://github.com/ansible-community/community-topics
18:53:32 <felixfontein> ompragash created a new repository (https://github.com/ansible-community/community-topics) which we can use to create issues for meeting agenda items
18:53:48 <felixfontein> this makes it a lot easier to track issues which are not discussed and finished in the next meeting
18:54:16 <felixfontein> I guess the main question is how do we want to use these issues w.r.t. the agenda
18:54:28 <felixfontein> that's why I created the meta-issue https://github.com/ansible-community/community-topics/issues/3
18:55:06 <felixfontein> one possibility (I thought of today) is to make the 'old' agenda (https://github.com/ansible/community/issues/539) read-only (i.e. lock the issue), and only post meeting minutes/summaries there
18:55:30 <felixfontein> and let the open issues in https://github.com/ansible-community/community-topics be the set of topics that can be discussed
18:55:32 <andersson007_> sgtm
18:55:49 <felixfontein> if we use labels to prioritize issues, I think this could work well
18:56:02 <andersson007_> sgtm as well
18:56:11 <felixfontein> we could also make https://github.com/ansible/community/issues/539 read-only, but someone posts a list of topics that probably will be discussed a few hours (or days?) before the meeting
18:56:31 <felixfontein> alternatively, people create issues and post a link in https://github.com/ansible/community/issues/539 for them to be discussed (so 539 is not locked)
18:57:03 <felixfontein> what does everyone else thinks about this?
18:57:06 <andersson007_> the last one doesn't sound good to me:)
18:57:11 <andersson007_> the alternative approach
18:57:23 <felixfontein> we don't have to decide now, but I think it's good to spent some thougts on this so we can decide soon
18:57:24 <andersson007_> locked imo would be better
18:57:37 <dmsimard> either way works for me, in any case it will help to have individual issues for some topics that are more long winded
18:57:46 <abadger1999> I like 2b.  Do you think it is still a managable amount of work?
18:57:47 <felixfontein> I also prefer to have a 'clean' agenda issue (539), i.e. no "random" "let's discuss XXX" posts
18:58:01 <andersson007_> +1
18:58:10 <felixfontein> I also like 2b)
18:58:24 <samccann> I like the idea of having an agenda. It can be a list of issues we'll talk about, or even its own issue that is opened before the meeting and closed after. But keep the minutes all listed in the old agenda issue
18:58:38 <samccann> searchable minutes are most helpful
18:59:05 <felixfontein> if we only have minutes in that issue, we can also stop hiding older ones (at least for some time)
18:59:25 <cybette> +1 for 2b)
18:59:37 <abadger1999> If we manage the agenda with labelled issues, would we be able to link to the search for that label and that == the agenda?  Or do we also need some way to order the list?
18:59:52 <felixfontein> having a separate issue, or an entry in 539, for listing the topics for every meeting is a lot of work though (since someone woul dhave to do that before the meeting)
19:00:34 <cybette> cyb-clock chimes: 7 min on topic "Meta: how to add things to the agenda" and 1 HOUR into the meeting!
19:01:10 <felixfontein> abadger1999: the problem with searches for issues is that they don't allow to order the issues by specific labels (AFAIK)
19:01:17 <abadger1999> Yeah
19:01:21 <felixfontein> abadger1999: so we'd need one search query per priorization level
19:01:41 <felixfontein> (or maybe the list of open issues is short enough to do that on the fly :) )
19:02:12 <felixfontein> I guess for the next couple of meetings, we can simply look at the list of open issues, and it won't be too long
19:02:21 <samccann> if the open issues are prioritized, that could be the 'agenda'.. or we have a 'next_meeting' label to add to the ones we know we need to discuss
19:02:34 <felixfontein> samccann: next_meeting sounds like a good idea!
19:02:54 <gundalow> I like the idea of next_meeting
19:02:56 <bcoca> that is how i like to solve everything, reschedule for 'next_meeting'
19:03:06 <felixfontein> everyone in the steering committee should be able to add/remove labels in that repo (it's not the case yet I think)
19:03:28 <felixfontein> if we run out of next_meeting issues during a meeting, we can still pick another open one :)
19:03:56 <Tas-sos> +1 for LTS versions
19:04:10 <felixfontein> :)
19:06:39 <gundalow> felixfontein: ah, yes, need to create a GitHub team for Steering Committee
19:07:31 <tadeboro> I like the idea of one issue per item because we can act on that item without making a mess. And closing the things once we handle it will feel nice.
19:08:04 <felixfontein> ok, I think I'll sum that up in the meta-issue, and then we can discuss again next week or even vote on it :)
19:08:09 <felixfontein> #topic Open Floor
19:08:22 <felixfontein> anything for the open floor?
19:08:40 <felixfontein> (which is not a trapdoor you can fall through)
19:08:50 <cybette> lol
19:09:34 <felixfontein> I'll close in a few minutes if nobody has a topic
19:09:52 <tadeboro> Is there a plan on how to manage unresponsive inclusion candidates?
19:10:09 <felixfontein> not yet
19:10:22 <felixfontein> I guess they will just miss the inclusion deadline
19:10:23 <tadeboro> I went through candidates yesterday and quite a few of them are not doing much.
19:10:52 <tadeboro> But do we want to keep that request open or should we close it after some time of inactivity?
19:11:06 <felixfontein> I guess the problem is if they do nothing until a few days before the deadline, and suddenly address all issues so far, and then expect to be included
19:11:08 <Tas-sos> About LTS versions.. (sorry for the delay)
19:11:21 <tadeboro> Infoblox comes to mind here.
19:11:56 <felixfontein> tadeboro: maybe some mechanism like needs_info with ansibot/ansiblebot, we post it, and if they don't reply in two weeks, we close the request
19:12:23 <felixfontein> I guess it would need a vote at the meeting though (both for establishing this meachanism, and for actually adding the needs_info IMO)
19:12:41 <Tas-sos> I start to understand the may be we have more problems because of collections.. but,
19:13:02 <abadger1999> I'd be okay with closing after a period of inactivity.  Maybe giving them a full cycle or something, though.
19:13:04 <tadeboro> For now, a simple policy would probably do. We can close the issues manually once we discover that they are marked as inactive for certain amount of time.
19:13:38 <tadeboro> This is why I mentioned Infoblox that missed the first inclusion and is again on its way of missing it again.
19:13:39 <felixfontein> tadeboro: yep, no need for automation of the number of requests doesn't explode
19:14:14 <andersson007_> I hope with the updated readme there things will get more efficient
19:14:59 <Tas-sos> I think it is very important to have LTS versions - and I think you also understand the reasons...
19:15:00 <felixfontein> andersson007_: I hope, but I wouldn't be surprised if not everyone reads it...
19:15:02 <Tas-sos> So for that I suggest to have a version that will be supported for at least a year
19:15:34 <cybette> cyb-clock chimes: 1 hr 15 min into the meeting
19:15:44 <tadeboro> Tas-sos: We need to convince collection maintainers to maintain some version of collection for a year then.
19:16:17 <felixfontein> which is probably next to impossible, especially with all the grandfathered collections
19:16:26 <tadeboro> And from what I have seen so far, most community collection will have little problem with that, but non-community content is the one I am worried about.
19:16:37 <felixfontein> if we'd start with an empty set of collections, we can ask for it (we'd have to define what happens if they don't do it though)
19:16:42 <aminvakil> tadeboro: +1
19:18:30 <felixfontein> ok, I think we can also continue this discussion after the meeting, since we're basically re-iterating what we had when this topic came up
19:18:33 <felixfontein> #endmeeting